muster release v5.28.2

Fixed

• A 429 on a session’s initialize is a transient refusal, not a legacy SSE server. When a remote MCP server answered a person’s session initialize POST with 429 Too Many Requests – GitHub’s hosted MCP server does when many tool calls of one session are in flight – muster logged failed to initialize MCP protocol: ... server returned 4xx for initialize POST, likely a legacy SSE server and sent whoever read the log after a transport mismatch that was not there. mcp-go reduces every 4xx on the initialize POST to that one sentinel and drops the status; the per-session client (DynamicAuthClient, the person’s grant, a forwarded or exchanged token) never typed it, so the connect failed with the generic message while the tool-call path already named the status. Now a 429 or 503 to the initialize is classified as retry-later on both connect paths: the client records the status and the Retry-After header off the wire and returns a typed InitializeRefusedError carrying both, the log and the CR status name the status (endpoint answered the initialize POST with HTTP 429 Too Many Requests; retry after 1s), the reconnect is scheduled for the Retry-After the server asked for rather than muster’s doubling backoff, and the session’s grant is kept so the next call reconnects. The generic 4xx message no longer claims a legacy SSE server for a status that has its own meaning – likely a legacy SSE server is said only for the 405 that means it. The scenario oauth-session-initialize-429-is-retry-later answers one grant-adoption initialize with 429 and Retry-After: 1, and pins that the server stays connected, the log names the status without the legacy-SSE line, and the next tool call succeeds without a reconnect. (#1303)