muster release v5.37.3

A token-forwarding session survives a fresh token its backend refuses on a pooled connection. Right after the identity provider rotated its signing key, a gateway that has not yet fetched the new key answers a new login’s token with 401 on every request of the session’s connection, not only on the connect the fresh-token handling covered: the capability poll’s re-listing logged “failed to list tools … authorization required” and was not retried, and a tool call retired the session’s authentication and asked the person to sign in to muster again although the login was valid. Such a 401 (a token issued within the 6-minute JWKS window, naming no cause but a key) is now judged on the token the request presented, as on a connect: a tool call keeps the session’s connection and gets a transient error to retry shortly, and muster re-lists the session’s capabilities on its own on the short backoff (15 s doubling to 2 min) until the backend accepts the token. A 401 for an older token, or one naming another cause, keeps today’s handling. (#1429)