Preserve the lead agent and model when delivering teammate messages #37

What problem does this solve?

Ensemble delivers teammate messages to the lead via OpenCode promptAsync.
When the receiving lead session is using a non-Build agent, such as Plan,
the injected message can start the next prompt loop using OpenCode's Build
agent and default model instead.

This defeats Plan mode's safety boundary: a lead that was intentionally in
Plan mode can automatically continue in Build mode after a teammate message,
before the user has an opportunity to send another message or restore Plan
mode.

Example correspondance:

• “[Original user request]” — agent: plan
• “[System: New team message from writer-exceptions]” — agent: build
• “[System: New team message from field-contracts]” — agent: build

Here, my original content was with plan, but it ended up being build - and then the session proceeded to modify files & do commits. That was unfortunate. :)

Environment:

• OpenCode: 1.18.25
• Ensemble: 0.17.0
• OS: Windows

What would you like to see?

Preserve the receiving lead's active agent and model when Ensemble injects a
teammate notification.

Specifically, when calling client.session.promptAsync to deliver a message
to the lead, Ensemble should determine the lead's current agent and model at
delivery time and pass them explicitly in the request.

For example, if the lead is currently using plan, the injected teammate
message should use agent: "plan" rather than falling back to Build. The
same should apply to the active model when it is known.

Desired behavior:

• A Plan lead remains a Plan lead after teammate messages.
• An Explore lead remains an Explore lead after teammate messages.
• Notifications do not silently select Build or change models.
• If Ensemble cannot determine the current recipient agent/model, it should
  fall back to existing behavior and log that fallback clearly.

This appears feasible because OpenCode's promptAsync API accepts explicit
agent and model fields.

Alternatives considered

• Change OpenCode's global default agent. This is not a reliable fix and would affect unrelated sessions.

The current README documents the behavior as a limitation, but preserving the
agent/model in Ensemble's promptAsync call would avoid the unsafe fallback. But it seems that this limitation is gone, at least as of OC 1.18.x.. :)