Version negotiation mechanism exists but HOST behavior doesn't change based on negotiated version

We're implementing a HOST using AppBridge and noticed a structural gap between the specification and the current SDK implementation.

What the SDK does

The negotiation mechanism exists in _oninitialize (source):

const protocolVersion = SUPPORTED_PROTOCOL_VERSIONS.includes(requestedVersion)
  ? requestedVersion
  : LATEST_PROTOCOL_VERSION;  // fallback to latest

However:

1. SUPPORTED_PROTOCOL_VERSIONS currently contains only one entry ("2026-01-26")
2. Neither the HOST SDK nor the App SDK changes behavior based on the negotiated version
3. @mcp-ui/client's onInitialized callback doesn't expose protocolVersion to HOST implementors

The concern

When a second spec version is eventually added, HOSTs have no guidance on how to handle apps built against older versions. The MCP Apps spec defines that protocolVersion should be exchanged, but doesn't specify what should happen on a mismatch.

The SDK comment (source) says "Apps and hosts don't need to manage protocol versions manually", but there is currently no HOST implementation guide and no version-specific behavior in the SDK.

Questions

1. Is there a plan to implement version-specific behavior in the SDK when a second spec version is added?
2. Should HOST implementors handle version differences themselves, or will the SDK abstract this?
3. Should onInitialized in @mcp-ui/client expose the negotiated protocolVersion so HOSTs can act on it?

Start by reading _oninitialize in src/app-bridge.ts and the protocol-version comment near lines 210-214. Then inspect @mcp-ui/client's onInitialized callback. Done would require an agreed version-negotiation behavior and a documented decision about whether HOSTs receive the negotiated protocolVersion.