muster release v5.27.10

A remote MCPServer whose endpoint answers the initialize with a 4xx is retried. A forwardToken server registered while its backend did not serve the path yet – a rollout in progress, the previous pod answering 404 – failed its registration probe with server returned 4xx for initialize POST, likely a legacy SSE server, read Failed and was never re-probed: the answer was not classified as a connection failure, so no retry was scheduled, and the sessions connecting later with their own token do not touch the CR’s state. The server stayed Failed (and MusterMCPServerFailed fired after 20 minutes) although the backend had been serving the path since seconds after the registration. Such an answer now enters the reconnect schedule like a refused connection or a 5xx: retried with the same backoff, the MCPServerFailed event and status.lastFailureHTTPStatus naming the status mcp-go dropped (endpoint answered HTTP 404, next retry in 30s at ...), and the server settles on its own once the path answers – in Auth Required for a server connected per session, Connected otherwise. The state rules of a per-session server (Failed only while the endpoint does not answer, Auth Required until the first session connects, Connected from then on, a later session’s failure never the server’s state) are documented in the CRD reference. (#1295)