PR #455 follow-ups: ring-scale probe can't fail on its layout half, stale body record, ring viewport reads nf-1863 ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/469 by tools/beads/import_github.py's reconcile pass.

Suggestions from ninefold-reviewer's review of #455. None gated the PR — it converged at coverage=12/12 tier=3 — and none is urgent. Filed so the tension leaves the review thread.

1. ring-scale.json asserts the text half of its configuration, not the layout half

tools/probes/ring-scale.json exists to cover one screen × 200%, the product #440 calls "the case that actually bites" and where H1, I2 and J1 all lived. It pins the text half hard (expect_focus "🔠 text size: ◂ 200% ▸"), but one-screen mode rides on two unasserted ui_accept presses on the layout row. In split × 200% the ROut viewport clamp never engages, RingFit returns ok trivially, and the run stays green while covering nothing.

single-screen.json already solves this two steps after the identical navigation. One line after the flip closes it:

```json { "expect_prop": "CellSize", "is": "128x112" } ```

Same shape as the note on single-screen.json's CellSize in the pass-6 verdict: at 8 bars the adaptive branch computes fit = 154, which clamps to want = 128 — the same value the untrusted-avail branch returns. So that assertion proves the boost arrived but cannot distinguish a working adaptive clamp from one that never runs. A second expect_prop after a + bar walk to ~12 bars would close that one.

2. The PR body's record stops at pass 2

#455's body ends at *"Review round 2 (pass 2)"*. Passes 3–6 landed ScText/InOverlay, the LayoutScale clamping, the adaptive CellWidth machinery, the layout-row RaiseChanged and RingScale — none of it recorded there, only in the comment thread. The Test plan still says *"Sweep, all green (14)"* over a 14-name list that predates single-screen-pill.json and ring-scale.json, against the 16 the latest reply reports; one-screen-song-2x.png is still cited as what a one-screen load looks like, pinned at 6a29640, which predates the adaptive width entirely.

The body is what survives a squash-merge, so this is the copy that becomes the permanent record.

3. RadialMenu re-reads the viewport many times per frame

ROut calls GetViewportRect() and — under LayoutMode.Auto — DisplayServer.WindowGetSize() via TonapseOptions.SingleScreen. After the J1 fix, RingScale, LabelW, LabelH and RingFs each call ROut, and Radius calls it twice through RIn. A 10-wedge _Draw now does roughly 25 of each per frame while the ring is open, plus ~50 more across Open()/LayoutLabels()/Refresh().

It is a transient overlay so nothing is visibly wrong, but caching ROut (or RingScale) per frame is a few lines. The wider version of this is TonapseStyle.Fs()/Sc() themselves reaching DisplayServer.WindowGetSize() on every call under Auto.

4. PianoRoll note-letter size rounds up one step

Fs(CellH >= 24 ? 8 : 7) renders 10 px where the pre-#455 code drew 9. Deliberate-looking but undocumented; either pin the intent in a comment or drop back a step.

5. single-screen.json shot ordinals don't follow step order

single-09-modal-fits-at-one-screen is captured between single-03 and the hint assertions, so the numbered filenames no longer read in run order. Cosmetic, but the ordinals are how a reader reconstructs the run from probe_out/.

Not included

The one-screen × 200% CONTROLS-guide wrap ("select" breaking mid-word, "rename / delete" running vertical) is already open as #456 with needs:direction and a default shipping — it wants Aedan's call, not a follow-up.