Verify cross-body row-window sync (availableRows vs mounted rows)

Context

Split leaf from #12930 AC4 ("Secondary row-window desync either resolved by the same fix (with evidence) or split into its own leaf with the captured data"). The id-migration seam fix landed via PR #12938 (c3d372054) and #12930 closes on its regression net; this leaf carries the captured secondary so it cannot silently vanish with the parent's close.

Release classification: boardless — verification residual of the #12930 family; escalates to the board only if the live recount shows the invariant still broken post-c3d372054.

The Problem (captured data, 2026-06-11 ~23:0xZ, operator devindex session 948c9bba)

All three region bodies reported availableRows: 16 / startIndex: 0 while mounting 18 / 22 / 22 rows (center / locked-start / locked-end). Each body was internally consistent (its own vdom == DOM), but the cross-body invariant — same row window across regions for one logical grid — was broken.

Staleness caveat (why this is a VERIFY ticket, not a FIX ticket): the capture predates the entire #12938 fix family. The duplication corruption active at capture time held BOTH cell/row generations in the DOM, which plausibly inflates mounted counts — the desync may be an artifact of the now-fixed defect rather than an independent seam. No post-fix recount exists.

The Architectural Reality

• src/grid/Body.mjs derives availableRows from container height / rowHeight and the mounted row set from startIndex + buffer math (createViewData path).
• Since the multi-body migration (#9486 / 36b45d700), src/grid/View.mjs#syncBodies owns the cross-body window orchestration (startIndex/visibleRows pushed into each body under skipCreateViewData) — the invariant's single writer.
• Possible legitimate variance to rule IN/OUT during verification: per-region bufferRowRange application could make mounted counts differ from availableRows by design; 18 vs 22/22 across regions of the SAME grid is the suspicious part, not mounted > available per se.

The Fix (verification protocol)

1. On a post-c3d372054 build (devindex or the #12936 examples/grid/lockedColumns fixture from PR #12945), connect Neural Link and read all three bodies: availableRows, startIndex, bufferRowRange, items.length, DOM row count.
2. Sample at rest → after vertical scroll → after a column drag (the original corruption trigger).
3. Clean (counts coherent under one documented rule): close this ticket with the recount evidence.
4. Dirty: re-scope this ticket into a fix leaf with the fresh capture; board it (the grid-corruption family was flagged release-blocking in the #12696 triage override).

Acceptance Criteria

• Post-fix recount executed on all three bodies across the three sample points, numbers recorded on this ticket.
• Either closed-clean with evidence, or re-scoped to a fix leaf with fresh capture + board attachment.

Out of Scope

• The id-migration seam (fixed, c3d372054; regression net on #12930).
• The view-level stale-baseline update race (#12939) and the in-flight wedge (#12946) — sibling lanes.

Related

• Parent context: #12930 (AC4 origin) · Fix family: PR #12938 · Siblings: #12939, #12946 · Fixture: #12936 / PR #12945

Live latest-open sweep: checked latest 20 open issues at 2026-06-12T02:55Z; no equivalent (#12946 = vdom in-flight wedge, different layer). A2A in-flight sweep: clean — no competing claim on the row-window scope.

Origin Session ID: c29b5ccc-d711-4cde-8401-32d1e4bbc4f1

Retrieval Hint: "cross-body row-window desync availableRows mounted rows recount post-fix"