Two annotate.spec.ts scenarios fail only under the local gate's ten workers

[JArmandoAnaya]

Two scenarios in frontend/app/e2e/annotate.spec.ts fail or go flaky under the local gate's ten
workers, and pass every time when the same names are run on their own:

• selecting on the canvas scrolls the object's row into view (line ~1475)
• a frame goes out for review, comes back, and is accepted the second time (line ~2455)

Reproduced on unmodified main at a2af0bf, on an 8-core Intel i9-9880H:

CI=1 VISIONSET_PW_WORKERS=10 pnpm exec playwright test e2e/annotate.spec.ts --reporter=line
  1 failed
    [chromium] › e2e/annotate.spec.ts:1475:1 › selecting on the canvas scrolls the object's row into view
  1 flaky
    [chromium] › e2e/annotate.spec.ts:2455:1 › a frame goes out for review, comes back, and is accepted the second time
  84 passed (1.6m)

Both pass in isolation at the same worker count, which points at contention rather than at the
assertions. VISIONSET_PW_WORKERS is deliberately separate from CI and is set to ten for a
developer's machine while Actions keeps the count its runners were measured at, so this is a shape
CI does not see and a local gate does — which is the wrong way round for a gate somebody is meant
to trust before pushing.

The first one asserts a scroll position, which is the class of assertion most likely to be decided
by how long a frame took. The second walks a whole review round trip and is the longest scenario in
the file. Neither is a claim about timing, so if the fix is a wait it should be a wait on state
rather than on the clock — the discipline e2e_discipline.test.mjs already enforces elsewhere.

gallery.spec.ts's own flake (#511) is a separate scenario and may or may not share a cause; worth
reading together, since a single answer about how much this suite can be parallelised on a
developer's machine would settle both.