What happened?

When the Control UI receives a gateway connect failure with details.code = PROTOCOL_MISMATCH, it can treat the close as recoverable and schedule reconnects even though a protocol mismatch requires a version update/reload rather than retrying the same client.

There is also a related detail-normalization issue for bare "protocol mismatch" errors: the UI formats the message with enriched protocol details, but the GatewayRequestError.details field keeps the original details, so later reconnect policy cannot read the normalized PROTOCOL_MISMATCH code.

Reproduction

On origin/main at 21d1e1f0fc9d:

1. Start a Control UI gateway connection.
2. Return a failed connect response with:

{
  "code": "INVALID_REQUEST",
  "message": "protocol mismatch",
  "details": { "code": "PROTOCOL_MISMATCH" }
}

3. Close the socket with the connect-failed close code.

Expected behavior

The Control UI surfaces the protocol mismatch and does not auto-reconnect. Bare protocol mismatch errors should also carry normalized details so reconnect policy can classify them consistently.

Actual behavior

PROTOCOL_MISMATCH is not included in the non-recoverable connect-error codes, so the close path can schedule another connection attempt. Bare mismatch errors only enrich the display message, not the stored details.

Environment

• Source checkout: 21d1e1f0fc9d
• OS: Windows source checkout
• Area: Control UI gateway connection / authority pairing startup