test(desktop): stabilize keyboard community reorder

[kiranmagic7]

Summary

Wait one browser timer tick after the keyboard drag is picked up and before sending ArrowUp.

@dnd-kit's KeyboardSensor calls handleStart() synchronously, then installs its document keydown listener inside setTimeout. Pick-up state is already visible during that gap, so waiting for aria-pressed cannot prove that the listener is ready. Crossing the macrotask boundary directly closes the race. Product behavior is unchanged.

Related issue

Fixes #4530. The source-derived mechanism and independent evidence are documented in #6007; that issue also tracks three separate flakes outside this PR.

Testing

• On current upstream/main (d8281b9c9), the isolated test failed 18/30 runs with retries disabled.

• With this patch, the isolated test passed 60/60 runs with retries disabled:

  CI=1 pnpm --dir desktop exec playwright test tests/e2e/community-rail.spec.ts \
    --project=smoke \
    --grep 'keyboard reorder' \
    --repeat-each=60 \
    --workers=1 \
    --retries=0 \
    --reporter=list

• just ci

• Screenshots are not applicable; this is a test-only change.

[kiranmagic7]

Re-checked the current head 09bb0cbbe82f98958b14723c24cf20cf816aa4d1: the branch is still mergeable, and DCO, Semgrep, and zizmor are green. The Buzz CI and Desktop Release Candidate runs are still waiting on fork-workflow approval with zero jobs, so there is no failing hosted log for me to fix.

Review focus is the one-file Playwright synchronization in desktop/tests/e2e/community-rail.spec.ts; the PR body has the 20/20 repro and verification against #4530.

[kiranmagic7]

Current main now covers this with stronger event-based synchronization in #8023: it waits for KeyboardSensor activation (aria-pressed) and the move announcement before dropping, rather than relying on a timer tick. That supersedes this branch’s timeout-based fix, so I’m closing it to avoid carrying a conflicting duplicate.