[BUG] Desktop: BYO OAuth MCP connect fails with malformed "Issuer mismatch (RFC 8414 §3.3)" error — same version-negotiation probe as #87713

## Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report
- [x] I am using the latest version

Related prior art in the same subsystem: #87713 (version-negotiation probe
misclassifying client-side OAuth errors), #90970, #88370. None reproduce this
exact symptom.

## What's Wrong?

This is a **regression**: this exact Snowflake MCP connector worked in Claude
Desktop a few days ago and started failing with no changes to our config
(exact prior-working date/build not captured). It now fails every time.

Connecting a Claude Desktop HTTP MCP connector configured with a **BYO OAuth
client** (`oauth.mode: "byo"`, explicit `clientId`/`clientSecret`/
`authorizationServer`) against a Snowflake-hosted MCP server fails
consistently with:

```
Version negotiation probe failed: Issuer mismatch in authorization server metadata (RFC 8414 §3.3): expected "https://.snowflakecomputing.com/oauth%22, received "https://.snowflakecomputing.com/oauth%22
```

Two things indicate this is a client-side bug rather than a real metadata
mismatch:

1. **The error is byte-identical across materially different configs.** We
tested: (a) the account hostname in the case documented by our internal
setup guide, (b) the same lowercase, (c) a from-scratch, manually-typed
(no paste) minimal config with only one `authorizationServer` field. All
three produced the exact same error text, including the `%22` artifact —
config content has no effect on the reported "expected"/"received" values.
2. **The message template itself is malformed.** Both `expected` and
`received` open with a literal `"` but close with the literal characters
`%22` instead of an actual `"` — on both sides, identically. That's
consistent with a broken string-interpolation in the probe's error
formatter (e.g. a hardcoded `%22` where a real quote character or a
`encodeURIComponent`-style escape was intended), not a genuine RFC 8414
issuer comparison failure.

We independently confirmed **Claude Code CLI** (`claude mcp add-json`, same
server URL, same account hostname, same OAuth client ID/secret) connects and
authenticates successfully against the identical MCP server. This isolates
the bug to Claude Desktop's MCP connect path.

This also reproduces **cross-platform**: the reporter is on Windows, and a
colleague independently reproduced the identical error on macOS against the
same server — ruling out an OS-specific cause.

Given the identical "Version negotiation probe failed: ..." prefix and the
same BYO-OAuth-client scenario called out as broken in #87713 ("A
pre-registered OAuth client does not work around it ... the error is still
classified `transport`"), this looks like a sibling bug in the same
version-negotiation probe's error classifier/formatter — a different code
path than #87713 (which covers the *no-cached-tokens, first-connect* case)
but the same root feature.

## What Should Happen?

The client should either:
- Correctly compare the issuer values (if there is a genuine mismatch) and
render the error with real values/quoting so users can tell what actually
differs, or
- Recognize this is a client-side probe/formatting bug and complete the OAuth
flow — as it does via Claude Code CLI against the identical server/config.

## Steps to Reproduce

1. Claude Desktop, Developer mode enabled → Developer → Configure
Third-Party Inference → Connectors & extensions → + Add → Blank.
2. Configure an HTTP connector against a Snowflake-hosted MCP server that
requires OAuth via a Snowflake External OAuth / Security Integration,
e.g.:
```json
{
"transport": "http",
"name": "snowflake_test",
"url": "https://.snowflakecomputing.com/api/v2/databases//schemas//mcp-servers/",
"oauth": {
"mode": "byo",
"clientId": "",
"clientSecret": "",
"authorizationServer": ["https://.snowflakecomputing.com/oauth"],
"callbackHost": "localhost",
"callbackPort": 8080
}
}
```
3. Click **Sign in & test** / **Apply Changes**.
4. Observe the error above. No browser OAuth window opens.
5. (Isolation) Configure the identical URL + OAuth client via Claude Code
CLI's `claude mcp add-json` and authenticate via `/mcp` — this succeeds,
confirming the server/account/credentials are correct.

## Error Messages/Logs

```
Version negotiation probe failed: Issuer mismatch in authorization server metadata (RFC 8414 §3.3): expected "https://.snowflakecomputing.com/oauth%22, received "https://.snowflakecomputing.com/oauth%22

Failed request
HTTP https://.snowflakecomputing.com/api/v2/databases//schemas//mcp-servers/ → initialize
```

## Is this a regression?
Yes. This exact Snowflake MCP connector worked a few days ago and started
failing with no config changes on our side (exact prior-working date/build
not captured, unfortunately). This matches the regression pattern already
established in #87713 (1.25927.0 → 1.32352.x broke first-time OAuth connect
for the same "version negotiation probe" subsystem) — suggesting an
auto-updated Desktop build is the trigger, not anything server- or
account-side.

## Platform
Snowflake-hosted MCP server (External OAuth / Security Integration, BYO
OAuth client, confidential client with client secret)

## Operating System
Windows (reporter). Independently reproduced on macOS by a colleague against
the same server/config — cross-platform, not OS-specific.

## Claude Code Version
Claude Desktop 1.49585.0 (41ad1d) — notably later than the 1.32352.x build
cited in #87713, so this is not fixed by that later release.

---

*(Account hostname, database/schema/server names, and client ID redacted as
``/``/``/``/`` — real values are
internal infra and shouldn't go in a public issue.)*

Start by tracing the Claude Desktop HTTP connector's version-negotiation probe for BYO OAuth and reproduce the failure with the Snowflake MCP configuration described in the issue. Compare its issuer-metadata handling with the successful Claude Code CLI flow; done means the issuer error, if genuine, shows the actual values correctly and the valid OAuth flow can complete.

由索引模型根据 Issue 内容生成。