Verify MCP server identity and refresh tool metadata after runtime changes

Problem

An MCP host can continue using tool metadata from a previous server runtime after the configured package, executable, or server release changes. This is especially confusing when a checkout is updated but the host still launches a pinned package version: request fields and advertised schemas can then disagree with what the operator expects.

The host should be able to tell whether the server it initialized is the server whose tool catalog it cached.

Proposed outcome

During MCP initialization and tool-catalog refresh, retain and expose the negotiated server identity and a deterministic tools/schema fingerprint. When the identity or fingerprint changes, invalidate stale tool metadata and re-run the catalog handshake. The UI or agent-visible diagnostics should make the mismatch actionable, including the resolved server version and refresh/restart guidance.

This is related to #19155, but focuses on binding cached metadata to the negotiated server identity rather than only refreshing after a restart.

Reproduction shape

1. Configure a stdio MCP server using a pinned package or executable.
2. Change the configured release or its tool schema without changing the host session.
3. Reconnect or inspect the active tool catalog.
4. Observe that the host can retain metadata from the previous runtime or cannot explain which runtime supplied it.

Acceptance criteria

• The host records the server identity returned during initialization.
• Tool metadata is bound to a schema/catalog fingerprint.
• A changed identity or fingerprint invalidates or refreshes stale metadata.
• Diagnostics show the active identity and refresh reason without exposing secrets.
• Tests cover a server restart and a changed tools/list response.