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

`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.