Turn completion is blocked on git checkpoint capture; slow or hung git delays "done" by seconds to over a minute #23079

Version: 0.1.2-nightly.20261021.3473, Windows 11, Claude provider

What happens: After the model's final token, the thread keeps showing as working for a while before it ends. It's usually 1–4 s, and occasionally 20–70 s.

Cause: When the provider turn completes, the run moves to waiting. RunFinalizationService.finalize then calls CheckpointCaptureServiceV2.execute, which runs checkpoints.capture() (git), and only then commits run.updated { status: "completed" } in the same command as checkpoint.captured. Run completion visible to the UI is therefore gated on git.

Evidence from local traces/events:

• The provider result arrives ≤5 ms after end_turn (177 Claude turns checked), so the delay isn't on the provider side.
• orchestrationV2.checkpointCapture.execute takes 1.2 s at p50 and 1.7 s at max on a small repo; RunFinalizationService.finalize takes 2.9 s at p50.
• Two runs sat in waiting for 47 s and 72 s, then completed with checkpoint missing + error. On this machine slow disk I/O likely made git stall, but any slow or locked git (large repos, AV scanning, index.lock) hits the same path.
• capturedAt is read before the capture runs and is used as occurredAt for run.updated. Event timestamps therefore hide the delay entirely, which makes this hard to spot from the event log.

Proposed fix:

1. Mark the run completed (or a UI-terminal "finalizing" state) as soon as the provider turn reaches a terminal state. Capture the checkpoint in the background and attach it with a follow-up event (e.g. checkpoint.captured + run.updated { checkpointId }).
2. Put a timeout on checkpoint capture (~10 s) and fall back to checkpoint: missing instead of holding the run.
3. Take capturedAt/occurredAt after the capture finishes, or record the duration, so slow captures show up in diagnostics.