Second review round: name the page that actually scrolls

From the review of 07ad947.

**The baseline was re-taken while the keyboard was up.** `focusin` captured
unconditionally, so tapping from one field to another — search box to composer,
which is exactly the sequence the discriminator asks for — took the SHRUNK
viewport as the "before". The shrink then measures zero and a keyboard plainly up
reads as absent. Capture only when there is no baseline; `focusout` already
clears it when focus really leaves.

**The comment named the wrong mechanism.** It credited "the same scroll-into-view
that keeps xterm's pinned helper textarea above the keyboard" — but measured at
390x844, html, body, #root, .app, .main, .term-host, .pane-reader and .cxv all
have a scroll range of exactly 0. A scroll-into-view inside this document moves
nothing. The reveal is the PARENT page's, wholly, and the comment now says so:
this document's job is to not fight it by resizing itself against a keyboard it
cannot see.

**And what `focusBaseline` is for now.** Since the estimate went, it sizes
nothing — its one consumer is the keyboardLayout label that only ?vvdebug=1
reads. Said in both places, so it is not mistaken for load-bearing, or for dead.

Also fixed the readout's own comment, which still described multiplying by a
constant that no longer exists.

tsc clean, exchanges ok, production build succeeds. The measurement above was
taken in headless Chromium against the extracted mobile CSS chain; it says where
scrolling can happen, not what iOS does with a keyboard. Still needs a phone.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

web/src/App.tsx

@@ -138,7 +138,9 @@ export default function App() {
     const keyboardSignalThreshold = 80;
     // The viewport as it was before a field took focus — the only thing left
     // that needs remembering, because a keyboard is detected as the SHRINK from
-    // it (hasKeyboardGeometry), not as an absolute height.
+    // it (hasKeyboardGeometry), not as an absolute height. Since the estimate
+    // was deleted this feeds no layout at all: its one consumer is the
+    // keyboardLayout label, which only ?vvdebug=1 reads.
     let focusBaseline: ViewportBaseline | null = null;
 
     const acceptsKeyboardInput = (target: Element | null): target is HTMLElement => {
@@ -183,10 +185,17 @@ export default function App() {
       // is wrong in the safe direction is still wrong: the abandoned strip does
       // not stay hidden behind the keyboard, because the browser scroll-reveals
       // a focused field and drags it back into view. That strip is the blank
-      // band under the reader's composer. Leaving the viewport alone hands the
-      // job to the engine that can actually see the keyboard — the same
-      // scroll-into-view that already keeps xterm's pinned helper textarea
-      // above it.
+      // band under the reader's composer.
+      //
+      // What replaces it is the PARENT page's scroll, not ours: measured at
+      // 390x844, every box in this document — html, body, #root, .app, .main,
+      // .term-host, .pane-reader, .cxv — has a scroll range of exactly 0, so a
+      // scroll-into-view in here moves nothing. The reveal is entirely the
+      // embedder's, and this document's job is to not fight it by resizing
+      // itself against a keyboard it cannot see.
+      //
+      // Nothing below sizes anything: with the estimate gone, keyboardLayout is
+      // a label for ?vvdebug=1 to read. No CSS matches it.
       if (hasKeyboardGeometry()) root.dataset.keyboardLayout = 'browser-geometry';
       else delete root.dataset.keyboardLayout;
       root.style.setProperty('--vvw', `${Math.round(width)}px`);
@@ -222,7 +231,12 @@ export default function App() {
     };
     const onFocusIn = (event: FocusEvent) => {
       const target = event.target instanceof Element ? event.target : null;
-      if (acceptsKeyboardInput(target)) focusBaseline = captureViewport();
+      // Only when there is no baseline yet: tapping from one field straight to
+      // another keeps the keyboard up, and re-reading here would take the
+      // shrunk viewport as the "before" — after which the shrink measures zero
+      // and a keyboard that is plainly up reads as absent. focusout clears it
+      // when focus really leaves, so this stays fresh without being re-taken.
+      if (acceptsKeyboardInput(target) && !focusBaseline) focusBaseline = captureViewport();
       stabilizeFocus();
     };
     const onFocusOut = () => {

web/src/components/ViewportDebug.tsx

@@ -24,9 +24,10 @@ export default function ViewportDebug() {
     let frame = 0;
     let last = '';
     const history: string[] = [];
-    // vv.height while nothing is focused: what App.tsx's focusFallback later
-    // multiplies by its constant. In an iframe this is the FRAME's height, not
-    // the screen's — the discrepancy that makes the guess wrong.
+    // vv.height while nothing is focused. Nothing multiplies it any more — the
+    // estimate is gone — but it is still the number to compare against once a
+    // keyboard is up: unchanged here means this document got no signal at all,
+    // and inside an iframe it is the FRAME's height, not the screen's.
     let baseline = window.visualViewport?.height ?? window.innerHeight;
 
     const num = (n: number) => String(Math.round(n)).padStart(4);