Persistent top-bar indicator for the conversation you are in — get back to it from anywhere

[serge-ivo]

The ask

While talking to an agent — especially hands-free — I should be able to navigate anywhere in the
console (Usage, Terminals, another agent's Board, Preferences) and still see a conversation
indicator in the top bar, and click it to jump straight back to the agent I am talking to.

Why it is missing today

The conversation is a property of the page, not of the app. pages/InstanceDetail.tsx owns the
chat, the voice state and the mode; navigate away and the top bar (components/Layout.tsx:12,
navItems) shows only static destinations. Nothing anywhere says "you are mid-conversation with
FWS platform".

That is tolerable when you type. It is not when you are hands-free: the mic may still be live, TTS
may still be speaking, and the only way back is to remember which of a dozen agents it was and
navigate through the instance list.

What it should be

• A persistent top-bar affordance whenever a conversation is active — agent name or icon, plus
  a state dot (listening / speaking / working). One click returns to that agent's Assistant tab.
• Active should mean voice is engaged (tap-to-talk or hands-free) or a run started from that
  chat is still going. The second case matters: [bug] Navigating back loses 'working on it' — the run is still going and the API already reports it #252 established that a run outlives the tab, so the
  indicator is also the honest answer to "is something still happening?" from anywhere in the app.
• Visible on mobile, where this hurts most — the instance tabs are already icon-only and
  scrollable, so this needs to be one icon, not a label.
• It should survive route changes, which means the conversation's identity has to live above the
  page: a small app-level store (or context) holding { instanceId, name, voiceMode, runActive },
  written by InstanceDetail and read by Layout.

Interaction with the mic

Decide explicitly, because silence here is a bug either way:

• Does navigating away keep the mic open? If yes, the indicator must show it unmistakably — a
  live mic on a page with no chat visible is a privacy surprise. If no, say so when it closes, since
  the user may still be mid-sentence.
• Does TTS keep speaking while away? Probably yes, and that is fine — but the indicator should show
  "speaking" so the source of the voice is obvious.

Related

• Voice command "next" — switch to the agent that wants you, without touching the screen #277 — voice command "next" to switch agents. Same problem from the other side: that one moves
  you between conversations by voice, this one gets you back to one by hand. They should agree on
  what "the current conversation" is, and share the store.
• [bug] Navigating back loses 'working on it' — the run is still going and the API already reports it #252 — run state is already fetched per instance; the indicator is a natural consumer.

Verification

• Start hands-free with agent A, navigate to Usage: the indicator shows A and its state; clicking
  returns to A's Assistant tab with the conversation intact.
• Works on a narrow screen without pushing the existing top bar into a second line.
• With no active conversation, the top bar is unchanged.
• Whatever is decided about the mic, the indicator's state matches reality — never "listening" when
  the mic is closed.

[serge-ivo]

Sequencing risk I under-weighted

This proposes hoisting the conversation — and, for #277/#279 to work, the voice session — above
the router. Direction is right. But packages/sdk/src/voice/use-voice.ts is 1341 LOC and
growing (#138 asks for it to be split; it has gained 19% since that ticket was filed).

Hoisting a god-hook to application scope makes its failure modes global: a stuck mic, a leaked
audio context or a wedged TTS stops being one page's problem and becomes the whole app's. Today
navigating away is an accidental reset — crude, but it is a recovery path, and this removes it.

Sequence #138 first, or at minimum extract the STT/TTS lifecycle before hoisting. Otherwise
this ticket's real cost is "promote the least-tested, largest module in the SDK to global state",
which is not what it looks like from the title.

Also worth stating explicitly in the design: with voice global, something must own teardown.
Per-page unmount currently does it implicitly.