feat(overseer): conversational state across a voice relay — who holds the operator's open list? #228

The problem

The operator talks to a voice agent. The voice agent talks to an overseer session. Those are two different agents with two different context windows, and only one of them is in the conversation the operator thinks he is having.

While the operator works through a list by voice, the overseer is simultaneously being pinged by other sessions — peers reporting progress, asking for decisions, handing back work. In one real session today that was six interruptions the operator never saw, and correctly should not have seen.

But it has a consequence nobody designed for: the list being worked is held only in the overseer's head. Not the operator's (he is away from the keyboard, that is the point) and not the voice agent's (it never saw the peer traffic). Nothing in the system makes maintaining that list anyone's explicit job. Today it was reconstructed by hand on request, which worked precisely once and only because the session had not been compacted.

What is missing

1. An owned, surviving set of "things awaiting resolution with the operator".

Not a summary generated on demand — a tracked list that accrues as peers raise things, survives interruption and compaction, and that something is obliged to maintain rather than reconstruct. It is the conversational equivalent of the blocked-list, but for the human rather than for sessions.

2. Two different prompts, not one.

• The voice agent, when talking to the overseer — not the same as when it talks to any other session. It needs to know it is addressing something that will be interrupted mid-list by other agents, and that the thread of the conversation is not guaranteed to be held on its side.
• The overseer, when talking to the voice agent — it must know its output is bound for speech and that an incoming peer ping must not displace a half-finished conversation with the operator. Today an interrupting peer and the operator's next question are indistinguishable inputs.

3. A reliable signal that a voice agent is the caller.

Ideally telemetry. Failing that — and the operator's own suggestion, which is cheap and probably right — the voice agent simply declares it: "this is the voice agent speaking to you, not the operator". A convention costs nothing and works today, where plumbing a modality flag through every surface does not.

Relationship to #223

#223 is turn shape: a session knowing its words will be spoken, and answering accordingly. That is built and live.

This is conversational state across two agents. #223 without this is a half fix: output gets shorter, and the thread is still held nowhere. They should not be merged — but #223 alone should not be considered to have solved the problem.

Known today

• set_voice_mode only takes effect at session bootstrap, so a relay cannot switch a session mid-conversation.
• A session can only set its own mode, not that of the session it is calling — which is the direction that actually matters for a relay.

Scope

Upstream-shaped. Any HAPI user driving work by voice through a relay has this; it is not specific to this estate.