[FEATURE]: Ability for Agent to do append-only content generation without managing surfaces and surfaceIds

One source of errors that we've always had with Gen UI and A2UI is when agents don't manage surface IDs correctly, e.g. they create duplicate surfaces or forget to create surfaces at all.

In the most common Gen UI use cases, the agent is just generating content as part of a turn, and never needs to update that content, so there is no need for it to write, read or reason about surface IDs. We should have some well-lit path (even a default!) which makes it this way.

This would eliminate this class of errors, and reduce latency by reducing the output tokens necessary to express a layout.

## Option 1: Hide `surfaceId` from LLM and programmatically inject surface IDs instead

We make it so that the inference format doesn't have any concept of `CreateSurface`. Instead, the LLM just defines components and then we automatically add a `CreateSurface` message.
- The inference APIs need some concept of "parse session" or "turn" etc, so that they know when to inject a new `CreateSurface` message with a surfaceId, and then add that surfaceId to all subsequent updateDataModel and updateComponents messages. We probably need this anyway, to help with validation.
- We can just use UUIDs etc for surfaceId
- This could be an option in the Express inference format etc, for chat use cases. Perhaps a boolean config like `manageSurfacesAutomatically`.

## Option 2: One MessageProcessor per Turn

We could recommend an integration approach where each turn in a conversation has a separate message processor handling the messages for it.

On the agent, we prompt it to just create a surface with any ID, or use option 1) above to inject some arbitrary surface ID so the LLM doesn't need to express it.

There are never surface ID conflicts, because each Turn now has a separate surface ID space. The downside is that the server does not have any ability to update surfaces on previous turns, because new content is always fed to a brand new `MessageProcessor`. But this is fine, and better, for most chat-based use cases.

## Recommendation

I think we should do option 1 first, because it is simpler to set up for the developer, and it's a nice step towards 2) anyway.