muster release v5.7.18

Fixed

• An MCPServer configured for session-level auth (spec.auth.forwardToken, or tokenExchange.enabled) is no longer registered globally with a token-less client when its backend answers muster’s connection probe anonymously — for example the old, anonymous pod during a rollover to an OAuth-protected release. The decision to handle a server per session now comes from the server’s own definition rather than from the aggregator registry entry that only exists after a registration (and is gone while the reconciler restarts a changed server): the service treats the accepted anonymous probe like a 401 — the probe client is closed, the server reports Auth Required, and every session connects with the caller’s own token — and the aggregator refuses to attach a shared client to such a server on any path. Previously the shared client 401-looped once the protected pod took over and every session’s tool call failed with authorization required until muster was restarted. A behavioral scenario (oauth-sso-forwarding-anonymous-backend) covers both a server created with forwardToken and one that gains it through core_mcpserver_update. (#1135)
• A pending-auth registration is no longer dropped by the aggregator’s handling of a stale service state-change event. The auth-required hook registers the entry synchronously on the server’s 401, while the starting event from the same start is still queued for the aggregator’s event handler; the handler declines to deregister a server whose entry says auth_required, but that check and the removal were two steps and the registration could land in between (the RegisteredAt guard did not catch it when the entry was created before the deregistration was timestamped). core_auth_login then answered “Server not found” until the periodic pending-auth heal ran, up to 5 s later. State-change-driven deregistration now decides under the registry lock and keeps entries that require per-session authentication; the paths for a deleted service are unchanged.