Design model for how an orchestrator will manage the surface ID space

Let's say we have multiple subagents rendering to the same client via an orchestrator. Each subagent will not necessarily be able to "see" (i.e. have in its context) all the different surfaces that the client is tracking in a "conversation" or "UI context" etc.

This means that each subagent could potentially choose surfaceIds which collide and break the rendering from the client's perspective.

We likely need to make the orchestrator prevent this by doing something like prefixing surfaces from subagents with some subagent identifier to scope the ID space, and do the inverse transformation when sending context back to subagents.

This will likely be one of many related issues around managing subagent graphs, e.g. what if we want to start sharing UI content between subagents as context etc.

Look at the orchestrator and subagent code to understand how surfaces are currently rendered and tracked. Examine the surface ID generation and management logic. The goal is to design a model that scopes IDs per subagent and handles transformations for client rendering and context passing.

Written by the indexing model from the issue text.