Mobile: rework the layout for touch — bigger type, reachable controls, less hidden behind density

[dnviti]

Problem / Motivation

On a phone, the app is a shrunken version of the desktop layout rather than a
layout meant for a phone. Everything the desktop shows is still on screen, only
smaller and closer together: the top of a conversation packs the project name,
a beta marker, token and cost figures, a status word, the approvals state and
five separate icon controls into a single band, and the row above the composer
does the same with attachments, mentions, commands, branch, model and send.

Two things follow from that. Text is small enough to be hard to read at arm's
length — several labels are meaningfully smaller than the body text, and some
carry information you actually need mid-session, like cost and model. And the
controls are packed tightly enough that hitting the intended one is a matter of
luck: they sit near the lower bound of what a finger can reliably hit, with
almost no space between neighbours, so a mistap opens the wrong panel or
toggles something you did not mean to toggle.

Density also hides things. Labels are truncated to a few characters, some
controls collapse to an icon with no text, and the rest is pushed behind a
"More" sheet — so on a phone a good part of the app is neither readable nor
discoverable, and the only way to find out what a control does is to press it.

The desktop layout is fine and should not change. This is about giving the
phone its own answer.

Goal

On a phone the app should read and behave like it was designed for one:
comfortably legible text, controls big enough and far enough apart to hit on the
first try, and the things you actually use during a session visible rather than
buried.

Scope

• A deliberate mobile type scale, applied across the chat surface — the
  conversation, the turn headers, the header band, the composer row and its
  labels — so nothing important is set in text too small to read on a phone.
• Touch targets sized and spaced for fingers rather than cursors, consistently
  across the header, the composer row, turn headers, panels, sheets and dialogs.
• A rethink of what the header band and the composer row show on a phone:
  what stays visible, what moves into a sheet or a second line, what gets a
  readable label instead of a truncated one or a bare icon.
• Layouts that use the phone's width instead of compressing desktop rows into
  it — wrapping, stacking or paging rows that today only fit by shrinking.
• The same treatment for the surfaces reached from the bottom bar and the more
  sheet, so the improvement does not stop at the main chat view.
• One place that defines the mobile sizing and spacing rules, so the surfaces
  agree with each other and future ones inherit it.
• Keep working within the space a phone actually leaves: the on-screen keyboard,
  the browser's own bars, notches and rounded corners, and both orientations.

Non-goals

• Any change to the desktop or tablet layout.
• New features, panels or capabilities — this is about presenting what exists.
• A visual redesign of the theme itself: colours, iconography and overall style
  stay as they are.
• The terminal's own on-screen controls, which were addressed separately.
• A native app or any app-store packaging.

Acceptance Criteria

• On a common phone screen, every piece of text in the chat surface is
  legible without zooming, and no label carrying live session information
  (cost, model, status, approvals) is set smaller than the body text.
• Every control a finger is meant to hit meets a stated minimum size, with
  enough space between neighbours that hitting the wrong one is not a
  routine occurrence.
• The controls above the composer and in the session header can each be
  identified without pressing them — by label, or by an icon whose meaning
  is confirmed some other way.
• Nothing in the mobile layout overlaps, clips or is pushed off-screen when
  the keyboard is open, in either orientation, on a small phone.
• Nothing that is reachable on a phone today becomes unreachable.
• The desktop layout is unchanged.
• The automated browser checks cover a phone-sized viewport, so these
  conditions are verified rather than asserted.

Suggested Phasing

1. Establish the mobile sizing rules — type scale, minimum target size,
   spacing — and add a phone-sized viewport to the automated checks.
2. Apply them to the main chat surface: header band, conversation, turn
   headers, composer row.
3. Extend to the surfaces behind the bottom bar, the more sheet, the panels and
   the dialogs.
4. Revisit what the header and composer row should show on a phone, now that
   there is room to make the decision honestly.

Open Questions

• When a phone cannot show everything at a readable size, what earns the space:
  the live session figures (cost, tokens, model), or the controls?
• Should the mobile treatment follow from the screen being small, or from the
  device being touch-driven? A touch laptop and a tablet in portrait answer
  those two questions differently.
• Is a user-facing text-size preference worth having, or should one well-chosen
  scale be the whole answer?