fix(web): let the statusline run be as tall as a real statusline

[stekman08]

One constant: MAX_STATUS_LINES: 3 → 8. A statusline taller than 3 rows made locateInputBox miss the input box, so sending from the composer stalled with the text already in the box.

What ships

• chrome.ts — the bound raised to 8, its comment rewritten to drop two claims that turned out false, and a schema docstring that contradicted the code corrected. 6 lines.
• chrome.test.ts — five blocks, red-first. Block 2 pins what actually protects the walk, which nothing checked before.
• .adr/0004 + a one-line rule in CLAUDE.md — the argument, because "just delete the bound" is what the next reader will reach for.
• bridge/journal/pi.test.ts — one line, unrelated, fixes two macOS-only failures. Flagged for splitting below.

No version bump — left the release commit to you, matching how #52 landed.

The bug

Sending from the composer intermittently fails with "Message didn't reach the input box — a dialog may be waiting. Nothing was submitted." The text is already in the pane's input box; only Enter is withheld.

locateInputBox accepts at most 3 non-blank, non-border rows between the input box's bottom border and the tail. That run is the statusline plus its hint rows — and a statusline's height is whatever statusLine.command prints. Nothing caps it: multi-line statuslines are an ordinary setup, generators in common use expose several line slots, and any row can soft-wrap into two on a narrow pane, which is the normal case on a phone. At 4 rows the border is never reached, extractInputDraft returns null, and sendGuardedReply stalls.

It reads as intermittent because statusline widgets are typically conditional — git state, PR state, a context meter — so a row appears and vanishes with no config change, carrying a pane over the threshold and back.

Same class as d9521e3, which admitted more rows under MAX_FOOTER_LINES = 8 when the background-agents footer broke this same walk: "it tolerated only the statusline window" (fixtures/panes/README.md:52-56). This is the statusline half, landing on the same number.

Why not just delete the bound

Because the reasons to keep it are two-thirds wrong, which is the trap. The old comment credited it with stopping unbounded stripping and with protecting dialogs below the box. Neither is true — step (c)'s border requirement does the first, and the blank line Claude paints above a dialog's footer hint does the second, in 20 of 20 dialog fixtures. Raising the bound even hedges less, not more, since dialogs are shorter than a tall statusline.

It's kept anyway, because an unbounded walk has no failsafe at all. Sized to 8 to match MAX_FOOTER_LINES.

ADR 0004 has the full argument (.adr/0004-the-statusline-run-is-bounded.md in this diff) — all four falsified justifications with the measurement that killed each, the two bounds' composition, and the consequences I'm accepting. Worth reading before the diff; it's the reason this is 8 and not 4, and the reason the constant isn't simply deleted. A short rule goes in CLAUDE.md per .adr/README.md's own division of labour. Happy to drop either if you'd rather own that text.

What it costs

Stated properly in the ADR's Consequences; in short: the scrollback-echo false-ENTER window widens from r<=3 to r<=8 (zero instances in 47 real captures, precondition absent from every real render, pinned as a known limitation in the tests); the composed ceiling with MAX_FOOTER_LINES rises from 12 rows to 17; and statusline rows past the first stop being rendered on panes this un-blocks, which is how every ≤3-row pane already behaves. Happy to follow up on that last one separately if you'd rather surface the whole run.

Tests

Red-first: blocks 1, 3 and 4 fail before the change (7 failures). Blocks 2 and 5 are invariant tests that pass before and after.

The one worth your eye is block 2 — all 20 dialog fixtures asserted safe at 3, at 8 and unbounded, plus an assertion that each one's tail run ends in a blank within 2 rows. That pins what actually protects the walk, and nothing checked it before. Block 5 pins all 29 real captures on {statusLineFound, draft, stripped}, taken from a pre-change run so it asserts an invariant rather than mirroring the new code; 0 of 29 move.

web: 92 files / 1311 tests green (was 1224). Root: 474 pass / 0 fail. Typecheck clean both sides.

One unrelated commit, flagged for splitting

bridge/journal/pi.test.ts fails two tests on macOS: the fixture builds its base from tmpdir(), which lives under /var/folders, and containedRealpath resolves /var → /private/var by design, so the returned path never string-equals the fixture path. Linux CI never sees it. One line — realpath the base first. All six tests in that block still pass, including refuses a symlink inside the root that points outside it; 18 tests before and after, no skip/only. Without it the pre-push hook can't run the backend suite on macOS. Say the word and I'll pull it into its own PR.

---

Two follow-ups I'm not doing here: plumbing Herdr's agent_status / scroll geometry into web/ would let box liveness be established rather than inferred from shape, which closes the echo class properly and lets the bound go entirely; and composer.tsx:299-316 fires its pre-clear sweep before sendGuardedReply, gated only on the memoized dialogPresent that agent-chat.tsx:192-194 itself calls "not load-bearing".

The constant's comment was rewritten in place, same line count, dropping the two false claims and pointing at the ADR. Say if you'd rather have the argument inline in the source instead.