Cowork: MCP App cards are live-turn only (no re-mount on session reload), and VM-bridge-routed tool calls never mount and strip result _meta

## Summary

Three related Cowork-surface defects prevent a spec-conformant custom connector's MCP App from being usable in Cowork, while the identical server works fully (mount + persistence + interactivity) in claude.ai Chat. All were isolated on 2026-08-17 against a custom remote connector (`https://mcp.andriani.ai`) after eliminating every server-side variable — the final server declaration is field-equivalent to connectors that demonstrably mount in Cowork (official Xero, Slack).

### 1. Cards do not re-mount when a Cowork session is reopened (most impactful)

- Cowork session `cse_01KAED2rLY4RY5TB3ikg7JcL`: the App mounted during the live streaming turn (iframe on `…claudemcpcontent.com/mcp_apps`, tool result rendered). Reopening the same session minutes later: **no iframe; the card is gone**. Only the plain tool row remains.
- Chat conversation on the same account, same connector, same day: the card **re-mounts on every fresh page load**.

Repro: run any interactive-connector tool in Cowork, watch the card render, reload/reopen the session. Consequence: anyone reviewing a completed Cowork task never sees the card, and the assistant's transcript claims a card that reviewers can't find.

### 2. Tool calls routed through Cowork's VM tool bridge never mount, and result `_meta` is stripped

Cowork appears to have two paths to a connector tool: host-level (preloaded tools; mounts Apps) and the VM tool-search bridge (transcript shows a "Found tools" step; never mounts). Which path a call takes looks nondeterministic and worsens as more connectors are enabled (~14 connectors / ~274 tools in this org). With only the one connector enabled for the task, calls route host-level and the App mounts (live).

The server returns result-level `_meta: { ui: { resourceUri } }` on `tools/call` (verified through `claude.ai/v1/toolbox/shttp/mcp/`), yet on the bridge path the Cowork-side model reports the result arrived as "plain JSON only … no MCP App / UI resource attached" — the bridge strips `CallToolResult._meta` before the model/renderer sees it, so even a self-describing result can't rescue the association.

### 3. Tool-name rewriting breaks the App association for spec-legal names

MCP tool names may contain dots (spec example: `admin.tools.list`). Claude's agent surfaces rewrite `.` → `_` before the model sees the name; the mount association then misses against the raw `tools/list` entry, while dispatch still succeeds — so the tool executes but its App never mounts, and connector settings still show the tool as interactive. (We worked around this server-side by renaming to `[a-z_]` names; other connector developers will hit it.)

## Environment

- claude.ai web (Chrome, macOS), Team org, Opus 5. Same behaviour observed in Cowork desktop.
- Custom remote connector: Streamable HTTP, stateless per-request transports (per the MCP Apps quickstart), `@modelcontextprotocol/ext-apps` 1.7.5 / SDK 1.30.0.
- Failing/succeeding Cowork sessions (this org): `cse_01KAED2rLY4RY5TB3ikg7JcL` (mounted live, gone on reload), `cse_01FZuminqzrRAWgAgEHQb1TY` + `cse_01DaE4jwtajpJohGozGNbGEy` (bridge-routed, never mounted, result `_meta` invisible to model), `cse_0198GUPvXYV7hA8aVCndH4bg` (pre-rename, dotted-name association miss).
- Control: official Xero connector card mounts in Cowork (`cse_019ZpGxHEjaiG7Ev4QbYxsfD`) — but is presumably subject to the same reload behaviour (#1).

## Expected

- Cards re-mount from stored transcripts when a Cowork session is reopened (parity with Chat).
- Bridge-routed tool calls preserve `CallToolResult._meta` and can mount Apps, or all interactive-connector calls route host-level.
- Mount association uses the same name mapping as dispatch after sanitisation.

Related: #165, #236, #471, modelcontextprotocol/ext-apps#671.