muster release v5.44.0

A subject-scoped issuer stays pinned while its MCPServer is down. An authorization server was pinned only once its MCPServer answered (connected, or 401 for a pending-auth entry), so after a muster restart with the issuer’s backend down, FetchSecret and the token broker answered “the person holds no grant” although the grant was intact in the store; a connected issuer whose backend then failed lost its pin on deregistration in the same way. muster now pins every MCPServer definition’s authorization server whatever the backend’s state (at start, on every MCP service event and on the 5 s reconcile tick), retries a deferred pin (Secret missing, OAuth not ready), keeps the pin when a Failed backend deregisters, and releases it when the definition changes or is deleted; the pin is logged at registration (Pinned authorization server … subjectScoped=true). (#1553)