test(#599): fix resize-then-measure race in e2e specs

[BorisTyshkevich]

What & why

Closes #599. Fixes a resize-then-measure race that made two e2e specs intermittently
flaky under parallel runs — surfaced originally while shipping #587 (phase 2 of #593),
and picked up now because the exact same failure signature hit CI twice in a row on an
unrelated PR (#601, phase 3 of #593) before passing on a third rerun.

Both sites read UI state (a bounding box, a persisted-then-republished data field)
immediately after triggering an async operation (page.setViewportSize, a click that
applies optimistically then commits separately), with no wait for the operation's real
completion signal:

1. tests/e2e/inspector-dock-layout.spec.js:147 — setViewportSize resolves as
   soon as the viewport is applied, but the displayed width is recomputed by
   app-shell.ts's reclampInspectorWidth, run from a real window 'resize' event
   listener dispatched asynchronously relative to that resolution. Under parallel
   load, the assertion sometimes read the pre-resize width.
2. tests/e2e/tile-open-workbench.spec.js:365 — the widen press applies
   optimistically first (runCommand, src/ui/dashboard.ts — its own comment says
   so), while the actual persisted commit is a separate, fire-and-forget
   app.mutateWorkspace(...).then(...) call. The test read the persisted value before
   that commit had necessarily landed.

Both are fixed with expect.poll(...) instead of a bare read on the next microtask —
same expected values, same assertions, just polled until they settle. The second fix
matches the pattern the same file's own later "narrow tile" test already uses for the
identical kind of read (its own "Read defensively" comment).

No production code changed — this is test-infrastructure only. The full audit
#599 asked for (checking both entire spec files for any other resize/state-change
immediately followed by a bare geometry/data read) found no further instance: every
other candidate site is either already polled or is a synchronous local-state read
gated behind a prior assertion that already guarantees the read is safe.

Verification

• Reproduced the actual CI failure: with the fix reverted, --repeat-each=15 --workers=12 (chromium+webkit) on inspector-dock-layout.spec.js reproduced
  Expected: 320, Received: 500 — the exact signature seen on CI.
• With the fix restored, the same stress level (--repeat-each=15 --workers=12, 240
  runs) passed twice in a row: 240/240 both times.
• Additional stress on inspector-dock-layout.spec.js: 3 rounds × 128 = 384/384
  passed (workers 8 and 12).
• Additional stress on the widen test: 3 rounds × 16 = 48/48 passed at
  --repeat-each=8 --workers=12.
• Isolated runs, 8× each (both projects): both specs 8/8 pass.
• Full parallel suite (--project=chromium --project=webkit), run 3×: 414 passed / 4
  skipped, 0 failed, every time — matching test(e2e): resize-then-measure race makes inspector-dock-layout and tile-open-workbench flaky under parallel runs #599's originally reported clean baseline.
• Coordinator independently re-ran the full local gate (check:types, check:arch,
  check:schemas, check:examples, npm test, npm run build) — green — plus 3 spot
  runs of both fixed spec files together — 29/29 passed each time.

Checklist

• npm test passes (the per-file coverage gate is non-negotiable)
• Tests added/updated in the same change as the code (this is the test change)
• npm run build succeeds (single-file dist/sql.html)
• Layers kept honest — test-only change, no production code touched
• No new runtime dependency
• README / CHANGELOG.md — no behavior change, so no entry needed (test-reliability
  fix only, not a feature or user-visible change)
• Reconciled affected tracked work — closes test(e2e): resize-then-measure race makes inspector-dock-layout and tile-open-workbench flaky under parallel runs #599, not part of the Umbrella: V2 architecture refactor — shell primitives, composition root, state reactivity, transport adapter #593 umbrella

🤖 Generated with Claude Code

https://claude.ai/code/session_01R32bb4VZGPgNo3tB9iVSKF

[BorisTyshkevich]

ChatGPT review pass 1

Reviewed head: 573ef7a83f477fb72bdb84dadab07c83c85199a2

Verdict: no actionable findings.

I reviewed the complete two-file PR diff, both full spec files, issue #599, the relevant app-shell.ts resize path, the dashboard.ts optimistic/commit path, the existing defensive poll in the narrow-tile test, and the current base divergence.

• The poll timeout is the Playwright expect timeout (5 seconds here; no repository override), not the 30-second test timeout. That is sufficient for the intended gaps: the resize handler is a direct, non-debounced style write, and the dashboard assertion waits for the serialized commit/republish path. A missing update remains a hard timeout failure rather than being masked.
• ?.items?.['t-sales'] ?? null cannot satisfy the expected object. Missing or transient state produces null, so the poll keeps retrying and fails on timeout if the commit never appears.
• The polls preserve the old successful-test ordering: the prior bare assertions could only pass after observing the same settled values. Subsequent actions therefore do not acquire a new timing dependency.
• I found no additional unguarded state-change → geometry/persisted-state read of the same class elsewhere in either file.
• The current PR merge ref passed the canonical Chromium e2e job: 209/209 tests.

The head is five base commits behind current main, but those changes do not overlap these specs or the relevant production paths, and GitHub reports the PR mergeable.

Execution note: direct clone and focused local Playwright execution were not possible in this review runtime because its execution container could not resolve github.com. I inspected canonical GitHub content and CI logs and ran a local semantic check of the optional-chaining fallback.