muster release v5.7.11

Fixed

• core_auth_login accepts an optional reset_client_registration: true. It discards muster’s stored RFC 7591 dynamic client registration with the server’s authorization server and registers again before issuing the sign-in link — the escape hatch for an authorization server whose refusal of the stored client_id the automatic checks below cannot see. Other users’ tokens from that authorization server may need a fresh sign-in afterwards, since their refresh tokens are bound to the old client_id.
• Stored RFC 7591 dynamic client registrations now heal themselves when the authorization server forgets them. Registrations without an expiry lived forever in muster’s credential store, so an authorization server that lost its client registry (pro keeps registered clients in memory; its pod was evicted during a node roll) answered every sign-in in the user’s browser with 400 invalid_client — a failure muster never saw — until an operator deleted the Valkey entry by hand. Before a sign-in link is issued with stored DCR credentials muster now verifies them: via the RFC 7592 client read when the registration response provided registration_client_uri, otherwise by asking the authorization endpoint with a client_id/redirect_uri-only request whose RFC 6749 §4.1.2.1 failure shape reveals whether the client is still known (a redirect to muster’s own redirect_uri: alive; a direct invalid_client: gone; anything else: inconclusive, credentials kept). A registration found dead is dropped and re-created within the same core_auth_login, logged at INFO. invalid_client from the token endpoint during the code exchange, or error=invalid_client on the callback, drops the stored registration too, so the user’s retry registers again.