fix(test): stop a swallowed Escape sinking the shortcuts sheet suite

[CompleteDotTech]

Fixes the Frontend build failure on main at f2fcd625f (run 32303914004) — 1 failed, 1 flaky, 3 skipped, 280 passed.

What failed

[desktop] › tests/keyboard-shortcuts.spec.ts › opens with ?, lists every catalog group, closes with Escape
  Error: expect(locator).toBeHidden() failed
  Locator: getByRole('dialog', { name: 'Command palette' })
  Expected: hidden
  Received: visible
    13 × locator resolved to <div role="dialog" aria-label="Command palette" …>
       - unexpected value "visible"

The failure is inside the gotoApp setup helper, not in any assertion the three tests actually make.

Not a regression from the dependency bumps

main@f2fcd625f and the PR head that preceded it (51a5dc914, #4739) have byte-identical trees — same tree SHA b274a2308534a4a4f1f3eaf5fb4c431f34e0ccc0, git diff between them is empty. That PR run was 282 passed / 0 flaky / 0 failed. Same code, different outcome, so nothing in the nanoid/postcss/sharp/serde_with work caused this.

Why a retry could not save it

useFocusTrap attaches its Escape listener and moves focus into the dialog in the same post-paint effect, and onKey returns early unless its trap is topmost:

if (!isTopmostTrap(trapId)) return;
if (e.key === "Escape") { onEscapeRef.current?.(); return; }

So a press that lands a beat early is dropped, not queued. toBeHidden() then polls a palette that will never close — which is exactly the shape of the log above: 13 consecutive resolutions to visible across the full 5 s window, a dialog that is persistently open rather than slow to disappear. That is why this failed outright instead of flaking to a pass on retry.

The change

Closing the palette is incidental here: the helper opens it only to prove the Workspace global-shortcut handler is live, and nothing in the suite covers the palette's own Escape behavior (grep "Command palette" tests/ matches this helper and nothing else). A one-shot press made that incidental step a failure mode for all three tests.

• Wait for the trap's observable half — focus inside the dialog — before pressing. This is the same guard right-chat-panel.spec.ts:189 already uses before its own Escape, so it matches existing convention rather than inventing one.
• Then press Escape until the palette actually closes, mirroring the open poll directly above it. Both loops stop on the first press that takes effect, so neither sends a stray key.

No source changes; tests/keyboard-shortcuts.spec.ts only, +27/−2.

Validation

• pnpm exec playwright test tests/keyboard-shortcuts.spec.ts --project=desktop --repeat-each=6 --workers=1 → 22 passed
• pnpm lint, pnpm typecheck → pass

What this does not claim

This hardens the helper against a dropped key; it does not fix why the key is dropped. I could not reproduce the gap locally — an instrumented probe over 8 serial runs found focus already inside the dialog at the moment visibility became observable every time (focusedAtVisible=1, 3–5 ms), so on an idle machine the window is effectively closed. The listener-vs-paint ordering above is a real property of the code and the log matches it, but the exact trigger on a loaded runner is inferred, not demonstrated. A topmost-trap conflict from another overlay would produce the identical symptom and is not ruled out.

Since the swallowed press is in setup rather than in a behavior under test, hardening it is the right fix either way — but if the palette's Escape path deserves its own coverage, that is worth a separate issue.

Tracked as cave-i1c. The second flaky test in that run, right-chat-panel.spec.ts:176 (also flaky in #4741), is untouched here and tracked separately as cave-ued — it passed on retry both times and has not been root-caused.