Derive chrome budgets from an explicit fixed-row list

[TheGreatAxios]

Summary

• provider-setup.ts's listHeight() subtracted a flat 14 from
  the terminal height, justified by a comment naming roughly nine
  rows plus unspecified slack — a guess re-guessed by hand whenever
  a row was added or removed.
• shell.ts already avoids this: it sums its ZoneId budget from
  PAINT_ORDER via resolveGeometry. That reducer is now factored
  into src/tui-opentui/geometry/chrome-budget.ts (chromeBudget),
  and both resolve.ts's sumChrome and provider-setup.ts's
  listHeight() call it.
• provider-setup.ts now names each fixed row it reserves in a
  CHROME_ROWS list and derives its list-viewport budget by summing
  it, rather than carrying a magic integer.
• A regression test mounts the surface and checks root's child
  count against CHROME_ROWS (minus root's own padding) plus the
  named alternate-step rows (loginBox/inputFrame/telemetry), so
  a row added to root without a matching entry in either list fails
  there — structurally, not just as garbled text on a short terminal.
• Audited landing.ts and stream.ts per the issue: landing.ts
  hands its boxes to shell.ts, which places them inside zones
  resolveGeometry already sizes, so it carries no fixed-row budget
  of its own. stream.ts has no renderable tree at all (pure
  data/layout functions). Neither needed changes.
• Does not route provider-setup.ts through resolveGeometry —
  that screen runs before a shell exists and was examined/rejected
  on real grounds; this stays the narrower convergence the issue
  asks for.

Stacks on #370 (cl-5412-picker-scroll, still open/unmerged),
which already adds flexShrink: 0 to provider-setup.ts's twelve
direct root children and replaces the flat 12 in listHeight()
with its own local named-term derivation. This branch was cut from
origin/main before #370, so it still touches the flat magic
number rather than #370's local derivation — expect a merge conflict
in listHeight() when #370 lands; the fix is to point #370's local
sum at the shared chromeBudget(CHROME_ROWS) helper added here.

Verification

• bun run typecheck — passes
• bun run build — passes
• bun run test (canonical, excludes vendor/) — 4038 pass, 0 fail
• bun test ./src ./tests ./evals --randomize --seed 42 — 4038
  pass, 0 fail (run twice to confirm stability)
• Rendered provider-setup.ts at 24/16/12/8/6 rows via the headless
  harness before and after the change: output is byte-identical
  between the old flat-14 budget and the new derived one at every
  height tested (the derived budget still lands in the same
  [LIST_ROWS_MIN, LIST_ROWS_MAX] clamp range). One rendering
  artifact at height 24 in the ad hoc capture script reproduces
  identically on unpatched origin/main, so it predates and is
  unrelated to this change — not something this issue's scope covers.

Closes CL-5599

[linear-code]

CL-5599

[TheGreatAxios]

Parking this. The derived chrome budget ships a regression: CHROME_ROWS excludes telemetry on the rationale that the step machine shows only one of loginBox/inputFrame/telemetry at a time, but telemetry.visible is set once at construction from showTelemetryNotice and never reassigned — so with the notice on it is visible alongside the list and competes for rows. The budget undercounts by 4 and corrupts text at every height, including 24, which the verification claimed was byte-identical.

The child-count test cannot catch it: a row added to CHROME_ROWS with a wrong rows value and no flexShrink: 0 still passes. Counted is not the same as safe.

This approach was also already tried and reverted on main today for the same underlying reason. Main now carries the flat rows - 14 with a comment stating plainly that it is a hand count that will go stale. That is honest and it works. Reopen if the shared derivation becomes worth another attempt.