feat: add MCP handshake test mode to Test Connection

[Altamimi-Dev]

Depends on IBM/mcp-context-forge#5934

Summary

UI half of the MCP handshake test, split out of IBM/mcp-context-forge#5934 now that the client lives in this repo — same pattern as #15.

Test Connection currently only proves a URL answers HTTP. This adds a second mode that proves the target actually speaks MCP.

• Mode toggle — HTTP request keeps the existing raw-request behavior; MCP handshake calls the new POST /v1/mcp-servers/test-handshake. Method, content type and body inputs are hidden in handshake mode since they don't apply.
• Detail rows on success — server name and version, protocol version, negotiation path (server/discover or initialize), and credential source (stored server credentials / form headers / none).
• Count badges — first-page tools/resources/prompts counts, rendered as 3+ tools when the backend's countsPartial flags a truncated listing (nextCursor present).
• Failure-class badge — Transport / Protocol negotiation / Authentication / Invalid response, alongside the backend's actionable error copy.
• Raw response — collapsible, truncated preview of the negotiated payload.
• Cancellation — the in-flight request is aborted on unmount, on Cancel, and when switching modes, so a stale response can't land on the new mode.

i18n

All new user-facing copy goes through react-intl (useIntl + intl.formatMessage), with keys added to the mcpServer namespace for en-US, es-ES and pt-BR. The en-US messages are byte-identical to the inline strings they replace, so the ported tests assert unchanged output. Component counts use ICU plural forms ({count, plural, one {# tool} other {# tools}}).

Two things stayed inline deliberately:

• The handshake Latency: … ms line — identical to the adjacent HTTP-mode line, which is not localized yet. Worth migrating together when this file gets a full localization pass rather than localizing one of the pair.
• The negotiation-path values server/discover and initialize — protocol identifiers, not prose.

openapi.json

The snapshot gained only .paths."/v1/mcp-servers/test-handshake" plus the GatewayHandshakeRequest / GatewayHandshakeResponse schemas, extracted from the gateway's app.openapi() on the #5934 branch. Everything else is untouched and the spec stays pinned at API v1.0.7 — a wholesale regen would pull in unrelated main-side drift ahead of the next version bump. All $refs in the added fragment (HTTPValidationError) already existed in the snapshot. npm run generate picks up the new endpoint and emits the handshake types.

Verification

• npm run generate — orval emits GatewayHandshakeRequest/GatewayHandshakeResponse types
• npm run test — 2821 passed, 1 skipped (157 files); TestConnectionPanel.test.tsx alone is 32 passed, including the 10 new handshake tests (mode switch, success detail rows, countsPartial badge, all four failure classes, abort-on-unmount, error-clearing on mode switch)
• npm run lint and npm run format:check — clean
• npm run build — generate + tsc -b + vite build clean
• git diff --numstat openapi.json — 280 0, purely additive

One note: npm run i18n:compile fails on this branch, but it fails identically on an untouched checkout of main (Error: No JSON file found in src/i18n/locales — compile-folder is pointed at the parent directory rather than the per-locale directories). Pre-existing, and happy to fix it in a separate PR if that's useful.

Relates to IBM/mcp-context-forge#5649 — the backend half is IBM/mcp-context-forge#5934; together they complete the issue.