Grouping-apply at 50k regressed from ~400ms to ~5-7s (#321); target-scale group benches report partial #500

Applying row grouping to 50k rows (S2 scale=target, group by col_5, 4 groups) takes ~5–7 seconds from setQuery to the first painted [data-pretable-group-row] on current main (a29298a). Before #321 it settled in ~400 ms on the same machine in the same session. The result: the group-expand and group bench scripts can no longer complete at target scale — waitForGroupedRowModel's 120-frame budget expires and the run reports partial (and group's measured window is cut off by the #326 row-count honesty check: "result row count settled at 50000, not the 50004 rows the plan handed the surface").

This was found while verifying #483 in a real browser. #483 is behaving exactly as designed — it refuses to measure and reports partial instead of emitting a number contaminated by the grouping render. The pre-#483 model-only gate fails at target too, so this is not the paint gate over-correcting.

Bisect

git bisect run over 33fd60f..5f59f86, driving the real measurement (bench:e2e, external server, S2/target/group-expand, judged on the summary's status):

• First bad commit: 72e7d47 — "feat: complete incremental row-model migration (feat: complete incremental row-model migration #321)" (merged 2026-08-11, hours after the perf(grouping): cut the expand-toggle window from 184 ms to 51 ms #297 session recorded group-expand at 51 ms).
• Adjacent pair is clean: 4bd57b3 (parent) → completed; 72e7d47 → partial.
• Same-session controls: 33fd60f → completed at 174.8–200.6 ms interaction latency (matches the recorded 183.7 ms base for that commit, so the harness and this machine are fine).

Scale dependence (current main)

Dev-scale latency matches the committed Aug-10 baseline median (8.4 ms), so the toggle itself hasn't drifted — what regressed is the grouping-apply settle, which #321's cooperative slicing appears to stretch from ~0.4 s to seconds at 50k. Not load: 1-minute load average during these runs was ~30–60, far below the 118–165 the Aug-11 numbers were recorded under.

Impact

• No target-scale grouping benchmark can currently produce a number, so the committed group-expand baselines (208.4 ms pre-perf(grouping): cut the expand-toggle window from 184 ms to 51 ms #297, 51 ms post-perf(grouping): cut the expand-toggle window from 184 ms to 51 ms #297) cannot be revalidated until this is fixed.
• If grouping-apply genuinely takes 5+ s at 50k in product too (nothing suggests this is bench-only — the probe watches the real grid), that's a user-visible regression, not just a harness budget problem. Raising waitForGroupedRowModel's budget would let the bench measure again but would paper over the settle cost; the settle regression is the thing to fix.

Repro (from a repo checkout, port isolated from other worktrees):

pnpm --filter @pretable/app-bench build
pnpm --filter @pretable/app-bench exec vite preview --host 127.0.0.1 --port 4519 &
PRETABLE_BENCH_EXTERNAL_SERVER=1 PRETABLE_BENCH_BASE_URL=http://127.0.0.1:4519 \
PRETABLE_BENCH_ADAPTER=pretable PRETABLE_BENCH_SCENARIO=S2 \
PRETABLE_BENCH_SCALE=target PRETABLE_BENCH_SCRIPT=group-expand pnpm bench:e2e