Killing the daemon and polling processExists wasn't enough — Windows can
delay releasing the cwd directory handle for tens of milliseconds after
the process object reports exit, so t.TempDir's RemoveAll still hit
"file in use by another process".

Add a best-effort retry loop (40 × 50ms = up to 2s) on resolvedRepo
inside the cleanup, gated to windows. Runs before t.TempDir's own
cleanup via LIFO, so by the time the framework cleans up there's nothing
left to delete and the spurious error is gone.

POSIX is unaffected: it ignores open handles when unlinking.

terminateProcess on the daemon PID alone wasn't enough on Windows:
crit's daemon polls `git status` once per second from watch.go and
spawns git/gh/sl subprocesses during diff/PR work. Each child inherits
repoDir as its cwd and holds an independent directory handle. Windows'
TerminateProcess does not cascade to descendants, so any in-flight git
child survived, kept the cwd locked, and t.TempDir's RemoveAll still
hit "file in use by another process" — a 2s retry loop wasn't enough
because a fresh git child can spawn every second the daemon is alive.

Wrap the spawned crit (and therefore its whole tree) in a Job Object
with JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE. Start the parent suspended,
assign to the job, then NtResumeProcess — closes the spawn-then-assign
race in which a child could escape the job. TerminateJobObject in
cleanup brings the entire tree down atomically; the existing per-PID
terminate path is kept as a safety net for the daemon itself.

Unix is a no-op (SIGTERM to the daemon is sufficient there, and Unix
doesn't hold cwd handles open the way Windows does).

Drop the now-redundant 40×50ms RemoveAll retry loop — the Job Object
kill is synchronous and complete.

SignalRoundComplete clears f.Comments synchronously and signals the
watcher to process the round; the watcher then runs git status, loads
disk, and calls carryForwardFileComments. carryForwardFileComments
unconditionally cleared f.Comments before re-appending carried-forward
PreviousComments, so any comment that landed between SignalRoundComplete
and the watcher's run was wiped out.

The race window is microseconds on Linux/macOS but widens on Windows
because git status and file I/O take noticeably longer there.
Symptom: agent posts a comment immediately after /api/round-complete
returns, comment briefly appears, then disappears when the watcher
finally processes the round; on the next finish-review the no-changes
overlay fires because only carried-forward comments remain. The
e2e-windows flake at round-complete.spec.ts:732 was the visible tip.

Filter f.Comments to preserve entries whose ID is not in
PreviousComments — those are brand-new for this round, not carry-forward
targets. carryForwardAllComments had a parallel bug: the
len(f.Comments) > 0 skip silently dropped PreviousComments for files
that only contained race-window-added comments. Replace the count check
with a CarriedForward marker check.

This is a real backend correctness bug, not a test-only fix; surfacing
it as Windows-only flakiness was an artifact of the platform's I/O
latency, not the symptom's cause.