Flaky e2e: empty-edit-delete.spec.ts:74 — empty-edit submit intermittently never opens the delete confirm dialog

Start with tests/e2e/empty-edit-delete.spec.ts at line 74 and inspect the clear-to-Enter sequence for the empty-edit case. Run the spec or the smoke shard command from the issue, then verify that the delete confirmation appears reliably and that the cancellation still keeps the message.

Desktop Smoke E2E (2) failed on attempt 1 of the CI run for #6542 at 0d7b21b356c842ad167d54a874bc9f378fe3c706, failing all three Playwright attempts, then passed on a re-run of the same job at the same SHA with no code change.

• Failed job (attempt 1): https://github.com/block/buzz/actions/runs/32782601230/job/97607837104
• Passing re-run (attempt 2): https://github.com/block/buzz/actions/runs/32782601230/job/97614178241

Failure

tests/e2e/empty-edit-delete.spec.ts:74 — "cancelling the empty-edit delete keeps the message" — timed out waiting for the confirm dialog:

const dialog = page.getByRole("alertdialog");
await expect(dialog).toBeVisible({ timeout: 10_000 });

What the artifacts show

The empty-edit submit never reached the confirm dialog on that runner — the dialog did not appear and get dismissed:

• The CI error-context DOM snapshot has edit mode still live and never exited: "Editing message" and "Cancel edit" both present, composer empty. No alertdialog node anywhere in the snapshot.
• The trace confirms the gesture ran in the intended order: edit-message click → edit-target visible → select-all → Backspace → empty assertion passes → Enter → wait for alertdialog.

So the state at failure is "editor cleared and Enter pressed, but the submit did not produce the dialog," not "dialog appeared and was lost."

Suspected mechanism

Async timing in the Tiptap clear→Enter sequence: the Enter keypress is dispatched before the editor's cleared state has propagated to whatever decides an empty submit routes to the delete confirmation, so the submit is treated as a no-op instead of an empty edit. Unconfirmed — it is consistent with the DOM evidence but I did not instrument the editor to prove it.

Not reproducible at this SHA

Checked at 0d7b21b356c842ad167d54a874bc9f378fe3c706 (git rev-parse HEAD confirmed in the same shell):

• The spec alone: passes 3/3.
• The exact CI shard, --project=smoke --shard=2/4 --workers=1 (336 tests): empty-edit-delete passed. Two unrelated specs flaked in that run — huddle-transcription.spec.ts:759 and inbox-live-update.spec.ts:281.
• The CI job re-run alone, same SHA, no code change: pass (16m52s).

Scoped negative: I did not find a reproduction locally in the same shard, or on a CI re-run at that SHA. I am not claiming this is a previously-known flake — I did not search the history of this spec for earlier occurrences.

Not a #6542 regression

The failure appeared on a run of #6542 (agent activity cover drawer), which had just moved edit-adjacent code, so it was worth ruling out:

• The spec never opens a cover drawer or the agent surface.
• The rebase did not modify the empty-edit path. The relocated pending-main-edit effect still gates on channelIsCovered (desktop/src/features/channels/ui/ChannelPane.tsx:551) with onEdit unchanged.
• Escape is not involved in this flow, so the cover drawer's Escape handling cannot reach it.

Ask

Evidence only, no fix here. If someone wants this hardened, it is a change to that spec's clear→Enter sequence (wait for the editor's empty state to settle before pressing Enter rather than asserting emptiness and immediately submitting) and should not ride along in an unrelated PR.