Realtime: the agent has no live channel roster — it cannot know which surfaces are open or what they hold

Observed on MJ 5.51.0, client-direct realtime session with two channels active (Whiteboard + Remote Browser).

## What happens

The agent cannot answer questions about its own surfaces: how many are open, which ones, or what each currently holds. It infers capability from the tools it was given ("I have `browser_*` tools, so there must be a browser") but has no knowledge of the live surface set, so it guesses — and guesses confidently.

## Why

At connect the model is told its **tool vocabulary**. It is never told the **channel roster**: which channels actually opened, which are focused, which failed to resolve a plugin, and what state each holds. `BaseRealtimeChannelClient` has `SerializeState()`, so per-channel state exists and is already persisted for resume — but nothing composes it into a description the model can read, and nothing tells the model when the set changes.

This is the same root cause as the Remote Browser staleness (filed separately as #3496): state exists on the client, and the model is only ever told about the parts it caused itself.

## Impact

It gets worse as channels multiply, which is the direction the channel system is clearly built to go. With one surface the agent can assume; with three it cannot, and "let me check the board" versus "let me check the browser" becomes a coin flip. Anything that wants to coordinate across surfaces has to route through a model that does not know what the surfaces are.

## Sketch of a fix

An authoritative live roster the host owns — the set of open channels with, per channel, its name, tab title, focus state, and a short channel-supplied state summary (an optional `DescribeState(): string` alongside the existing `SerializeState()`). Surfaced to the model at connect and refreshed on change, either as a context note or as a small read tool.

Worth noting that the same roster is what a per-channel close would mutate (filed separately) — one concept, two symptoms.

Filing as a report only, per our process — no PR attached.

Start with BaseRealtimeChannelClient and trace how SerializeState() is persisted for resume and how the client connects to the model. Map where channels open, focus, fail to resolve, and change state. Done means the host exposes an authoritative live roster with channel identity and state summaries at connect and after changes.

Written by the indexing model from the issue text.