Windows local teardown treats live startup contention as a cleanup failure #2598

Windows one-shot CLI clients can complete their work and then exit unsuccessfully while another client holds a startup gate.

This appeared twice in the cold-start storm guard for #2305:

• Run 38163898818: client 4 printed the list_projects result, then failed during cleanup.
• Run 38136360982: client 2 failed at the same point.

Both reported:

coordination.cleanup_timeout component=local_transition_cleanup action=process_exit
codebase-memory-mcp: coordination cleanup timed out (local_transition_cleanup); terminating so the OS releases retained claims

The relevant daemon IPC and CLI cleanup code in #2305 is unchanged from upstream main at 879c11ea.

Windows local teardown reacquires startup-v2 and the validated legacy mutex before releasing its participant claim. The release API currently reports both a busy gate and a native cleanup failure as false, so the caller gives both the same 500 ms deadline. A healthy peer can hold the startup gate longer than that.

Expected behavior: retain the participant claim and wait for healthy contention using the existing bounded startup policy. Repeated native cleanup failures should retain their short fail-stop deadline.

I’m preparing a focused fix with a native Windows regression that holds the startup gate beyond 500 ms after indexing completes, then checks that releasing the gate lets the client exit successfully.

AI assistance: investigated and prepared with Codex on behalf of Pcristin.