test(coordinator): pin the superseded-navigation cancel off the main thread

[datlechin]

Refs #2061.

#2055 moved the driver cancel for a superseded navigation off the main thread. The reasoning was sound and the unit tests were green, but nothing had ever observed the new code path run: the capture taken afterwards contained no hasInFlightQuery=true, so every supersede in it happened before a query existed to cancel.

This adds the automated guard. No production code changes.

What it pins

ScopedDriverCancellationTests seeds DatabaseManager.runningDrivers with a fake driver that records which thread cancelQuery() ran on, then calls cancelRunningQuery(for:reach:) directly:

• A .supersededNavigation cancel never runs on the main thread. This is the property the stall depended on. A PostgreSQL cancel opens a second connection to deliver the request, which through an SSH tunnel measured 68-157ms, and it used to be paid inline on the main actor.
• The cancel still arrives. It is fire-and-forget now, so the half worth checking is that it is not silently dropped. The issue asked for this explicitly.
• Stop still cancels inline, on the caller's thread, already done when the call returns. The user is waiting on Stop, so it must not become asynchronous.
• A .protectedWrite lease is never aborted, by either reach. The existing test for this only compared enum cases; this drives the real function.
• A supersede with nothing registered cancels nothing. The session-driver fallback aborts whatever the connection happens to be running without knowing what it is, so only an explicit Stop may take it.

The path needed no new seam. cancelQuery() is a nonisolated protocol requirement, runningDrivers and cancelRunningQuery are already internal, and the fake-driver pattern is used in 15 or so suites already. The fake is local to the file rather than reusing the shared MockDatabaseDriver, whose call counter is an unsynchronised var that would be a genuine data race now that the cancel runs off the main actor.

What it does not prove

It proves the dispatch, not the end-to-end number. The test says cancelQuery() runs on a background thread and cancelRunningQuery does not wait for it, which means the main thread cannot block on that round trip. It does not say the replaceTabContent gap over a real SSH tunnel is now single-digit milliseconds, because other work on that path could be slow for unrelated reasons. #2058 is one such thing.

So I would keep #2061 open until someone runs the capture in it. This changes it from unverified to mechanically guarded, which is not the same as observed.

Verification

7 tests pass. swiftlint lint --strict reports 0 violations. No CHANGELOG entry: tests only, no user-visible change.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.