Move the composer below the thread and show it only in text mode — the live dictation becomes the one surface above it

[serge-ivo]

The ask

"Replace the text box (at the top) with the actual message dictated, shown in realtime before being
sent — same for hands-free and push-to-talk. Move text entry to the bottom, as all messaging apps
do, and only show it in text mode."

Where the chat tab is today

┌─────────────────────────────────┐
│ textarea            ← TOP       │  :941-964   value = voice.interim || input
│ mode selector + actions         │  :966
├─────────────────────────────────┤
│ message thread (scrolls)        │
│   …messages…                    │
│   live dictation bubble         │  :1162   ← voice.dictation, LAST child
└─────────────────────────────────┘

Input above, thread below, and the live utterance at the far bottom of the thread.

The realtime display already exists

Worth stating before anyone starts building one: voice.dictation (#281) is already the realtime
dictated message. It appears as speech starts, keeps the words through the transcription round
trip rather than being overwritten by a "Transcribing…" sentinel, survives a failure with a Dismiss
affordance, and is cleared when the real message is appended. It works in both hands-free and
tap-to-talk.

So this issue is a layout change, not a new feature. The reason it reads as a missing feature is
#364: the composer still binds the dead voice.interim, so the surface the user watches shows
nothing while the working one sits off-screen.

The change

Invert the two, which is what "as all messaging apps do" resolves to:

┌─────────────────────────────────┐
│ message thread (scrolls)        │
│   …messages…                    │
│   live dictation bubble         │  ← now directly above the input
├─────────────────────────────────┤
│ mode selector + actions         │
│ textarea — TEXT MODE ONLY       │
└─────────────────────────────────┘

The dictation bubble ends up immediately above the composer without moving, because it is already the
last child of the thread. That is the whole point of the inversion: the realtime text lands where
the user is already looking, and there is exactly one surface showing it.

Decisions taken

Composer hidden outside text mode, per the ask. Consequence to accept knowingly: the tap-to-talk
placeholder currently reads "Use the voice control to talk — or type" (:951), so typing mid-voice
session is a supported escape hatch today and this removes it — the route becomes "switch to Chat".
The mode selector stays visible in every mode, so that switch is always one tap.

Two things that must move with it

Both are currently attached to the composer and would be orphaned by hiding it:

1. The audio-level meter (:955-959) is absolutely positioned against the textarea's bottom edge
   and is the only "the mic is hearing you" signal. In voice modes its host is about to disappear. It
   belongs on the dictation bubble or the status pill — both of which are present exactly when the
   meter is relevant, which the composer no longer will be.
2. The notice line — see [bug] Hands-free says "Listening…" and shows no words — the composer still binds voice.interim, which stopped carrying speech in #281 #364. voice.interim carries mic errors and the wrong-language
   warning through the input's value. With the input gone in voice modes, those errors have no
   surface at all, which is worse than the current confusion.

Sequence

#364 first — it is a deletion, it is the actual reported bug, and it can ship on its own. This one
then moves what remains. Doing this one first would leave the dead binding inside the restructure and
make the diff harder to read.

Not in scope

The thread's scroll anchoring already has form here (#335 — loadMessages scrolled unconditionally
while its siblings did not) and inverting the layout will touch the same behaviour. Worth re-checking
after, not worth pre-emptively redesigning.

[serge-ivo]

Shipped in e9d8b45 (CI green).

Premise checked first. The issue's map of the surface holds: the composer was above the thread (:937-962), the dictation bubble was already the LAST child of the thread (:1160), and the mic meter was absolutely positioned against the textarea's bottom edge. So the inversion really is a layout change, not a new feature — the bubble did not have to move at all.

What the composer actually did per mode, before: it was rendered unconditionally in all three. In Chat it is the input. In Tap-to-talk it showed "Use the voice control to talk — or type" and typing worked — a real, if undocumented, escape hatch. In Hands-free it showed "Listening…" and stayed empty for the whole utterance (#364: it binds voice.interim, which stopped carrying speech). In every mode it also carried the mic-level meter and, via voice.interim, the notice line.

Where a recovered turn's words go. They still go to the composer — that is why "only in text mode" could not be taken literally. classifyResult → recover fires in the voice modes by construction, and onRecoveredText writes into input. A literal mode === "text" gate would have deleted those words at the instant they arrived, silently, reintroducing #281/#175. The gate is shouldShowComposer({mode, draft, notice}): always in text mode; in a voice mode exactly when the box holds something — a recovered turn, a draft, or the notice line (#364's surface, also otherwise orphaned). It can never sit there empty during a voice session and can never swallow anything. Pure, in store/console/src/lib/composer.ts, with 6 tests.

Knowingly given up, per the ask: starting to type mid-voice-session. The mode control stays visible in every mode, so that is one tap.

The meter is rehomed onto the voice pill — the host that exists exactly when the meter is relevant (resolveVoiceStatus returns null only in text mode).

Scroll rule (#335) verified, not assumed. The scroll container is the same element with the same classes, so pb-16 still counts inside scrollHeight and BOTTOM_EPSILON_PX arithmetic is untouched. The jump button and the pill moved into a new thread wrapper so their bottom-3 keeps resolving against the thread's bottom edge rather than the composer's — measured in a browser: thread bottom 682px, pill bottom 670px, i.e. exactly 12px, unchanged. Composer show/hide does change the thread's height, so the existing re-pin effect now also fires on it — still only when atBottomRef.current, so a reader scrolled up mid-read is never yanked.

Measured in-browser (text mode): thread y 40 → 606, composer y 646. After switching to Tap-to-talk: composer count 0, mode control still present, thread grows 566 → 642.

Coordination with #364: I touched only position and visibility. The composer's binding (value={voice.interim || input}, its onChange, and the voice.interim ? "border-accent…" class) is byte-for-byte unchanged and still lives in the same JSX block, just relocated. The gate reads voice.interim as notice so the notice keeps a surface whatever #364 does with it.

Not in scope, as stated: the placeholder's ptt branch ("— or type") is now near-unreachable, but it is voice.interim-adjacent and belongs to #364.