muster release v5.31.4

Fixed

• A session on a forwarded bearer ends when the bearer expires. A caller that presents an IdP-issued token (an agent’s on-behalf-of token, a workload token of a trusted issuer) gets a session keyed by that token, with no refresh chain: the token is its only credential. The session outlived it. Its pooled backend connections kept forwarding the expired token on every capability poll and every listen-stream reconnect, each backend answered 401, and only the third rejection in a row evicted a connection, with a WARN for each – although the token’s exp was known the moment it arrived. muster now binds such a session to its bearer’s exp and ends it then, once: its backend connections are closed, its auth marks and capability entries dropped, and a server it held the last connection of goes back to Awaiting Session. The capability poll ends such a session instead of listing through it, and a forwarding connection whose session bearer reaches its expiry ends the session instead of counting strikes; the strike counter stays for undecodable tokens and for sessions that refresh (a person’s login). A trusted-issuer bearer never has a provider token in muster’s store, so that expected miss (SSO: Failed to get provider token from store: token not found, once per request) is logged at DEBUG; a miss for muster’s own access token and any store failure stay WARN. Scenario oauth-forwarded-bearer-expiry-ends-session; the harness gained test_get_mock_server_rejections, the backend’s count of 401s and of requests with an expired bearer. (#1323)