muster release v5.31.0

A pinned server can receive the person’s ID token next to its grant. A server that acts for the person on two systems needs two of their credentials – the grant of its pinned authorization server (a GitHub App user token, say) and the person’s own identity for calls back through muster – but an MCPServer carried one: forwardToken is rejected next to authorizationServer, so such a server was registered twice. spec.auth.forwardIdentity: true, valid only with type: oauth and an authorizationServer pin (CEL rule, and the same check in filesystem mode and core_mcpserver_validate), sends the session’s upstream ID token – the token forwardToken would put in Authorization, read on every request so a refreshed one is used – in the X-Muster-Id-Token header; Authorization keeps the pinned grant. A session without an upstream ID token sends no header, a server without the field never receives it, the server’s requiredAudiences are requested at login as for a forwardToken server, and a change of the field resets the sessions’ connections. As with forwardToken, the forwarded token is not audience-scoped to the server. muster create mcpserver gained --forward-identity. (#1317)