test(flaky): silence the FSWatcher echo and stop the sizing waits from giving up quietly

[rducom]

Two unrelated flakes surfaced in the same CI run (31976426203).

1. denseBurstCoalescesToItsClusterAncestor — reproduced

✘ IncrementalRefreshTests.swift:317: Expectation failed: (c.autoRestatCount → 2) == 1

The suite's premise — "forge FSEvents batches directly into handleDiskChanges — no FSEvents latency" — was never true. Self.scanned(root) calls scan(url:), which arms a real FSWatcher (1 s latency) on the fixture. The tests write real files, so the watcher echoes their own writes back a second later. That second batch re-marks paths the cycle already reconciled and lands as an extra re-stat or subtree pass.

Idempotent for the tree — which is why waitUntil still exits and the aggregate assertions pass — but fatal for anything that counts the passes. On a loaded runner a reconcile cycle (20 directories, parallel) outlives the watcher's latency, so the echo arrives while the test is still waiting.

The suite half-knew this already: preciseEventLeadsToRestatOnRefresh carried an NB: dropping a dirtyPaths.isEmpty assert for exactly this reason. The workaround was never generalised.

Fix. ScanController gains a liveWatchingSuspended flag — a flag rather than a bare stopWatching(), because a rescan re-arms the stream — and the scanned() helper pins the watcher off so the forged batches are the only input. The dropped assert comes back.

2. toggleAllCyclesTriState — diagnosed, not reproduced

✘ CleanupTests.swift:343: Expectation failed: (c.selectedRows.count → 1) == 2
✘ CleanupTests.swift:346: Expectation failed: (c.selectAllState → .all) == .some
… 3 more, the whole tri-state cycle shifted by one

Never fell locally in 40 loaded runs, so this one is a diagnostic rather than a reproduction — worth flagging when reviewing.

All five failures are consistent with a single cause: the test-cache-2 row was still .pending, so not bulk-selectable, so every step of the cycle shifts. Alternatives ruled out — blockedReason and detect are deterministic for that id, and a sized(0) would need the scanner to miss a 4 KiB file.

The culprit is waitForReady. It polls RunLoop.main.run(until:), and all 26 parallel @MainActor suites pump that same shared run loop, so each round costs far more than its 20 ms slice: the 5 s budget went to mutual blocking, not to work. Then it gave up in silence — which is what let a timeout masquerade as five incoherent assertions further down.

Fix. The deadline exists only to stop a hang, so it is now generous (60 s); more importantly both waits now #expect their condition, reporting timed out waiting for .ready, still sizing at the call site instead of failing obscurely downstream.

Verification

Full suite, 20 iterations, under 28 spinners on 14 cores:

	before	after
IncrementalRefreshTests:317	10 / 20 failed	0 / 20

SwiftLint --strict clean.

Out of scope

StructuralIntegrityTests.swift:33 also fell once in 20 loaded runs — not in the CI run above, and untouched here. The single await Task.yield() at line 29 assumes the child task reaches its first suspension in one scheduler turn; under load it sometimes runs to completion, ok is true and the file is really deleted. It needs an observable rendezvous point, so it belongs in its own change. Its 0/20 here proves nothing at a 1-in-20 rate.