Test sometimes cannot find a table cell that is on the page

## What happens now

Our automated browser tests sometimes fail because the test says it cannot find a table cell to click — even though the recording of that same moment shows the table and its cells sitting right there on the page, unchanged. The test waits ten seconds, gives up, and the whole run is marked failed.

This caused two of the three failed attempts in a continuous-integration run on 2026-08-24, so it makes the test suite look unreliable even though the editor and the syncing were working correctly the whole time.

## Example

This was recorded in the continuous-integration run linked in the notes. It has not been reproduced locally — it appeared under a heavily loaded machine — so the steps are the test's steps and the result is what the recording shows.

1. Run the two-window editing test that adds a list, an image with a caption, a table, and a quote, then edits each from the second window: `npm run test:e2e -- --repeat-each=8 -g "mix of block types"`.
2. On a busy machine, watch for the step where window B clicks into a table cell.

**What you see:** the test fails with a ten-second timeout waiting for `[data-type="core/table"] td`, reporting that no matching element exists.

**What you expected:** the click lands, because the table and both its cells are on the page — the failure recording itself proves they never left.

## What should happen instead

When an element is on the page, the test should find it and click it. A failure like this should only happen when the element is genuinely missing.

## How we will know it is done

There is no reliable trigger yet, so the first deliverable is an explanation: why did the element lookup return nothing while the page contained the element? Once the cause is known, either the test or the tooling gets fixed and the check is the same command passing all eight repetitions, twice in a row, on a busy machine:

```bash
npm run test:e2e -- --repeat-each=8 -g "mix of block types"
```

Needs a test — or at least a way to detect the condition and retry, once the cause is understood.

## Notes for whoever picks this up

**This is the face split out of #37.** That issue's 2026-08-24 CI evidence had two distinct failure signatures; the genuine sync symptom stayed in #37, and this locator anomaly moved here. The full analysis trail is in #37's comments (2026-08-24).

**The evidence, from the Playwright traces of [run 32784952985](https://github.com/Automattic/gutenberg-sync-engines/actions/runs/32784952985)** (both retry attempts, same signature): the locator `[data-type="core/table"] td` matched nothing for the full 10 s in window B. Meanwhile the trace's own DOM snapshots show the table subtree present and unchanged throughout — the snapshots are incremental, and the table appears as an unchanged-subtree reference, which is positive proof nothing in it changed. Same block id the whole time, a single editor canvas iframe with one blob URL (so no remount), no empty-table placeholder, no invalid-block recovery screen. Typing into the table's caption succeeded in the same window, so the page was interactive. The timed-out action's teardown snapshot marks the td as found again (the `__playwright_target__` attribute is present). And no sync traffic touched the table during the wait — every captured response was decoded; zero rows rewrote the table's `body` attribute.

**So the contradiction is:** Playwright's locator evaluation said "no element" for 10 s while Playwright's own snapshots of the same page say the element was there. The suspect is the lookup path, not the page — plausibly how the locator pierces into the editor's iframe under heavy load, or a stale frame handle inside Playwright. The click is issued by the spec's `clearAndType` helper in `tests/e2e/specs/collaboration-multi-client-content.spec.ts` (the td click around lines 210–213).

**Where to look first.** (a) Reproduce under load and capture Playwright debug logs (`DEBUG=pw:api`) to see which frame the locator queries. (b) Check whether the selector crosses the canvas iframe boundary the way the rest of the suite does — if the suite's other locators use a frame-scoped page object and this one resolves differently, that difference is the lead. (c) Known Playwright issues about locators in iframes returning empty under CPU pressure; check the pinned Playwright version's changelog before debugging from scratch.

**Trace-reading technique** (needed to verify any of this yourself): `.trace` files are newline-delimited JSON; DOM snapshots are incremental, so a node encoded as a reference means "unchanged since the referenced snapshot" — absence from a delta proves nothing, fresh serialization proves change. Response bodies live in `resources/*.json`, and each sync row's `data` field is a JSON string that must be decoded before searching, or escaping hides matches.

**Not a sync bug.** This issue is deliberately scoped to the test tooling. If investigation shows the element really did leave the DOM in some way the snapshots cannot see, move the evidence back to #37 and close this.