fix: prevent setCheckpoint from overwriting concurrent job state updates

[nigel-dev]

Summary

Fixes a race condition where setCheckpoint() in the orchestrator overwrites concurrent job state updates via savePlan() with a stale plan snapshot. This caused completed plan jobs to appear stuck as "running" when a sibling job fails.

Closes #63

Changes

• src/lib/plan-state.ts: Add updatePlanFields() — atomic read-modify-write for plan-level fields only (status, checkpoint, checkpointContext, completedAt, prUrl) inside the planMutex, preserving job states
• src/lib/orchestrator.ts: Replace all savePlan(staleSnapshot) calls in setCheckpoint, clearCheckpoint, _doReconcile, and resumePlan with updatePlanFields. Add reconciliation safety net that cross-references jobs.json to detect plan jobs stuck as 'running' when they have already completed or failed
• tests/lib/plan-state.test.ts: Add 5 tests for updatePlanFields (basic update, concurrent preservation, ID mismatch, no plan, checkpointContext)
• tests/lib/orchestrator.test.ts: Add updatePlanFields mock to all beforeEach blocks. Add race condition regression test and safety net test
• tests/lib/orchestrator-modes.test.ts: Add updatePlanFields mock to beforeEach block

Testing

• bun run build passes
• bun test passes (613/613)
• Manual testing done (if applicable)

Notes

• The root cause was handleJobFailed calling loadPlan() outside the mutex, getting a stale snapshot, then passing it to setCheckpoint() which called savePlan(plan) — writing the entire stale object back to disk, overwriting concurrent updatePlanJob() changes from handleJobComplete for sibling jobs.
• The safety net in _doReconcile is a defense-in-depth measure that detects jobs stuck as 'running' in the plan when jobs.json already shows them as completed/failed. This covers edge cases where the race condition may have already corrupted plan state before this fix was deployed.