CI runs the whole test suite on Windows and macOS too

The Build workflow's test job, before and after, on GitHub's runners (2,137 tests).

Before: the first run of the full suite on Windows

Platform	Result	Job time
Linux	green	1 min 33 s
macOS	green	1 min 45 s
Windows	10 tests failed	16 min 52 s

Run 42522272169

After: two runs with all fixes in a row

Platform	Result	Job time, run 1	Job time, run 2
Linux	green, both	1 min 49 s	1 min 47 s
macOS	green, both	4 min 20 s*	3 min 55 s
Windows	green, both	10 min 59 s	13 min 13 s

* Run 1 on macOS still had a browser-skill test that failed under load; it's fixed in run 2. Run 42526918768, run 42527969907.

The installer builds run alongside in about 9 minutes, so on a push to main the Windows test job is now the longest job: a run takes about 11–13 minutes instead of about 9.

What failed on Windows, and why

Review tests waited past their 25 s. Git answers came back through a step that Windows ran only once something else woke the test's waiting loop. They now come back through a timer, which works on every platform. This was the cause of the two review tests named on the card, and of a third.
Short folder names. GitHub's runner names its temp folder C:\Users\RUNNER~1\…, while git spells the same folder out in full, so tests took one folder for two. The test runner now uses the full name. This fixed four tests.
Tools and measurements the runner lacks: a test called the sqlite3 program, which Windows doesn't have; a speed test measured with the clock, which counts waiting for a core. They now read the database directly and count the CPU's own cycles.
Permissions that don't hold for an administrator: the runner's user could create a folder despite a deny rule. The test now blocks the clone in a way that holds for every user.
Waits that were too short on a busy machine (Koordinator, silent speech, browser skill): they now wait for the actual event instead of a fixed few milliseconds. The browser skill also took a slow browser for a dead one and threw its state away while the browser still ran; that was a real fault, now fixed.

Not seen

The intermittent "every free workspace has uncommitted changes" on a fresh clone didn't occur in any of the five full Windows runs (0 of 5), so there was nothing to trace. If it comes back, its message names the files.