Windows: taking a chat back to a computer it was on fails with "Access is denied" in the handoff swap #2565

What happens

On native Windows 11, moving a chat back to a computer it was on before fails. The handoff's swap (internal/handoff/handoff.go, swap) cannot set the old chat folder aside:

handoff: put <id> in place: rename <tmp>\<id> <tmp>\<id>.replaced: Access is denied.

In product terms, "Continue here" back and forth on Windows works the first time and fails on the second return to the same computer.

Reproduce

On native Windows 11 (NTFS, Go 1.26.5, Microsoft Defender real-time protection on):

go run ./internal/furrowbin/cmd/fetch -goos=windows -goarch=amd64
go test -count=1 ./internal/syncsetup -run '^TestTakeLedgerRemoteIdentityCombinations$'

Every subtest fails on its third take (A → B → A → B), with the error above.

Results

What it is not

• Not transient. Stretching fsreplace.Retry from 630 ms to about 11 s changes nothing; the handle is held through the whole take.
• Not the presence folder watch. The result is the same with the kernel watch disabled.
• Not the cellstore group commit. It also fails with the pre-Factory: any-source intake, router and AI filter (draft, e2e first) #2478 groupcommit.go.
• Not syncPath's file handle. Opening it with FILE_SHARE_DELETE changes nothing.
• Not git auto-maintenance. It still fails with maintenance.auto=false and gc.auto=0.
• Nothing visible on Linux. After B's chat closes, and again just before the third take, no process has an open file, a working directory or a memory mapping under B's chat folder (checked through /proc/*/fd, cwd and maps). Linux would not be blocked by them anyway.

Next step

Find the holder on Windows during the swap, with Sysinternals handle.exe or Process Explorer. Then check whether the GitHub runner passes only because Defender real-time scanning is off there.

Found while verifying #2546 on native Windows. #2546 does not block on this.