fix(sync): eliminate the tz-sync registration race that aborts scheduled runs

[dortort]

Problem

Scheduled tasks intermittently fail at the very start of a run: a sub-second exit-1 with empty stdout/stderr and no session ever created. On the affected machine this recurred roughly monthly against an otherwise-healthy task (mostly successful runs), always with the same signature.

Root cause

The daily tz-sync job (claude-scheduler-cli sync, which keeps local StartCalendarIntervals aligned to UTC across DST) is scheduled for 3am local — the same slot many tasks run at. When it fires alongside a task, sync mutates the very things that task's launch depends on:

• Hazard A — torn shim read. sync rewrites the shared executor shims (claude-scheduler-run, claude-scheduler-cli) in place. launchd can exec a shim mid-write and read a truncated file.
• Hazard B — reloading a live service. registerDarwin does launchctl unload → load on the task's plist. If the task's job is mid-run, launchd tears down its process tree; the executor records the killed child as code ?? 1 → exit 1 with empty logs.

Shifting a task off the 3am slot only lowers the probability — and sleep/wake coalescing refires missed jobs together anyway, defeating the offset. The durable fix addresses the coordination, at both layers.

Fix

1. Skip re-registering a task whose job is running (fix(sync), Hazard B). Before sync re-registers a task, it checks a new isTaskRunning predicate (reusing the executor's existing lock: readLockPid + verifyProcessIdentity + a liveness probe). A live task is deferred to the next sync cycle, so its already-loaded registration is never torn down mid-run. The predicate is injectable to keep the sync loop unit-testable.

2. Write plists and shims atomically (fix(platform,init), Hazard A). A new writeFileAtomic helper writes to a temp file in the target's directory and renames it into place. A concurrent reader always sees a whole file, regardless of timing — this closes the torn-read hazard that the per-task lock structurally can't reach (the shims are shared, and they're read before any lock exists).

The two layers are complementary: the lock guards the unload/reload path; atomic writes are an unconditional invariant for the file rewrites.

Deliberately out of scope (YAGNI)

• Reload-only-on-change — an optimization of how often sync reloads, not a correctness fix; once reloads are lock-guarded and writes are atomic, reducing their frequency buys nothing.
• Closing the launch-window sliver (the gap between launchd exec and the executor acquiring its lock) via a launchctl running-state query. The lock check already shrinks the vulnerable window from the whole run down to node startup, and a task missed by one sync self-heals on the next. Not worth the added complexity until evidence shows the sliver actually bites.

Testing

• writeFileAtomic: new-file, overwrite, mode preservation, no temp-file leak on success or failure.
• isTaskRunning: false for no-lock / unverifiable (no startTime) / dead-pid; true for a live, identity-verified process, flipping to false once it's killed.
• sync: a running task is not re-registered and lands in skipped; all tasks register when none are running.
• Full suite green (352 tests), typecheck and lint clean.