A piano-roll spec reaches its clip under the slow backend however busy the machine is #38

Under the slow backend, with Playwright's own worker count (5 on a 10-core machine), a piano-roll spec now and then never reaches the clip it moves to from the keyboard: toClip in frontend/e2e/helpers.js ends at its expect(item).toBeFocused() (line 56) with the clip "inactive" after 15 s. Seen on 3 November in both full runs of scripts/suite --slow, one red each, and nowhere else:

• piano-roll.spec.js:18 (GROOVE_SEED=1946234537) and piano-roll.spec.js:235 (GROOVE_SEED=4138500526), each in a full run; each passed three times out of three replayed alone with its seed.
• piano-roll.spec.js:447 and piano-roll.spec.js:490, in npx playwright test piano-roll.spec.js --project slow-backend --repeat-each 3 (2 failed, 43 passed), which is the quickest way seen to make it go red.

Since the same delays pass alone, what differs is how busy the machine is, so it is a race between a key pressed and focus moving, in the window or in the spec. The webkit project did not go red in either run. CLAUDE.md's rule holds: the window or the spec is fixed, never a timeout raised, and never a worker cap put back to hide it, since the suites are to run as fast as the machine lets them.

Done when npx playwright test piano-roll.spec.js --project slow-backend --repeat-each 10 is green, the four tests above among them, with Playwright's own worker count; and the change says whether it was the window (with a test that went red first) or the spec that pressed ahead.