Merge gh/main (4b88084) into wire2/2wu3

Resolved context/test-evidence/clients.md: gh/main's version, whose
improvise-w7qd/5kdr paragraphs continue the entry above the conflict,
followed by this branch's two improvise-0j0f/4img entries.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdfEGXA7aJ6ftMsCc9PJze

context/test-evidence/clients.md

@@ -4626,24 +4626,12 @@ before #178 too, as the review noted.
 **Fault injected:** the same pre-fix tree. Fails: the host stored
 `4598108823619341467` in South/Cost.
 
-### `every_build_that_parses_a_frame_enables_float_roundtrip`
-
-The two tests above run in **one** feature-unified test build, which includes
-`improvise-ws-server` and `improvise-command` as dev-dependencies. So they pass
-whenever **any** crate in that build enables the feature. The shipped browser
-bundle is built from one crate alone, so it would still be lossy. That was
-demonstrated: with the feature removed from `improvise-wasm-client` only, both
-tests stayed green while `cargo tree` showed no `float_roundtrip` in the wasm
-bundle. This test asks cargo instead, once per crate that parses a frame:
-`cargo tree --locked --edges normal,features --invert serde_json --package
-<crate>`, with `--target wasm32-unknown-unknown` for the two bundles. It uses
-normal edges only, because a dev edge would unify the feature back in
-(`context/repo-map.md`, `## Wasm`).
-
-**Faults injected:** the feature removed from `improvise-wasm-client` alone,
-which fails naming that crate while the two tests above pass. Then removed from
-`improvise-ws-server` alone, which fails naming it. The native path runs
-without `--target`, so the two arms are different invocations.
+**Retired: `every_build_that_parses_a_frame_enables_float_roundtrip`.** It asked
+`cargo tree` about three crates listed by hand. improvise-dz8c replaced it with
+`every_crate_that_can_parse_json_enables_float_roundtrip`, whose entry is in
+`tooling.md`. The injections recorded for it still hold: with the feature
+removed from `improvise-wasm-client` alone, the two tests above stay green, so
+they cannot guard the bundle alone.
 
 ### resolve::tests::every_grid_move_lands_where_its_binding_says
 
@@ -4677,6 +4665,43 @@ laundering invisible (the edge) is also the one that makes a wrong-direction
 jump visible, so moving off the edge fixed one blind spot and opened the other,
 and each needs its own question.
 
+**improvise-w7qd, and the floor was the hole.** As first written the test
+covered `move-selection` and a four-entry jump table, behind `pressed >= 14`.
+Two things passed the whole workspace, both found in re-review of #180 at
+544744c: negating the `scroll-rows` and `page-scroll` arms, so `Ctrl-d`/`Ctrl-u`
+and `PgDn`/`PgUp` all scroll the wrong way (advertised, and still "acting" from
+the centre); and dropping the jump table *with* `$` sent to the first column,
+because the sixteen `move-selection` sequences met the floor on their own. The
+test now walks **every** command Normal binds. `scroll-rows` and `page-scroll`
+state their landing from their own argument exactly as `move-selection` does —
+from the centre of a 3x3 grid any step of at least one lands at `1 + d`
+clamped, so a sign is visible whatever the page size — and a command that moves
+the cursor (in the same view) without a stated landing **fails** rather than
+being skipped. So a dropped table entry is caught by derivation, not by a count:
+under the second rival it fails naming every jump as moving with nothing stating
+where. The first rival fails on `PgUp` (`page-scroll ["-1"]`) and, alone, on
+`Ctrl-u` (`scroll-rows ["-5"]`). A last assertion that each kind was pressed at
+least once guards the other direction — a binding vanishing — and is a named
+list on purpose, since that is the one thing no walk over bindings can see.
+
+**improvise-5kdr: the 3x3 fixture saw only a sign.** From the centre of a 3x3
+grid every step of one or more clamps to an edge, so the w7qd version stated
+`page-scroll` as `1 + d` — one row, which is not what it does — and passed
+because the true landing clamped to the same edge. Measured on #198 at 8772db2:
+`page-scroll` ignoring the page size together with `scroll-rows` moving one row,
+or `move-selection` moving `2d`, left the test green. The walk now stands at
+(10,10) of a 21x21 grid with an 8x8 window, far from every edge, so a landing
+shows magnitude: `10+d` for `move-selection` and `scroll-rows`, `10 + page·d`
+for `page-scroll`, 0/20 for the jumps. The page size is not written into the
+test: `grid_move`'s page rule moved into `page_rows(window_rows)` and the test
+asks it, so the rule has one home. Rivals, each run: `move-selection` doubled
+fails on `Up` (`move-selection ["-1","0"]`); the page-size-and-one-row pair
+fails on `PgUp` (`page-scroll ["-1"]`); the one-row `scroll-rows` alone fails on
+`Ctrl-u` (`scroll-rows ["-5"]`); the jump-table rival still fails naming every
+jump. The residual, stated: because the test reads `page_rows`, a change to the
+page rule itself moves the test with it — whether that rule is the TUI's is
+`tests/lockstep.rs`'s question, not this one's.
+
 ### an_edit_is_refused_when_the_cell_was_written_while_the_editor_was_open
 
 improvise-0j0f, found by the review of PR #188 at 48f52e7 and confirmed