Prevent concurrent component installs from corrupting dependencies

[kriszyp]

Serializes component extraction and dependency installation across Harper worker threads, including the deprecated direct npm-install path. Installer process trees are now terminated on timeout, worker exit, and Harper shutdown; failed boot preparations remain retryable instead of being written to harper-application-lock.json.

Reviewer attention: filesystem lock ownership/recovery in componentPreparationLock.ts and process-tree lifecycle registration in manageThreads.js. Generated by Codex; the standard pre-PR review completed with Claude and Gemini, while the post-fix final-artifact Claude check ended with an internal execution error.

Closes #1973

[gemini-code-assist]

Code Review

This pull request introduces a file-system-based locking mechanism (withComponentPreparationLock) to serialize component preparation across worker threads, and implements process group tracking to ensure spawned child processes are terminated on timeout or worker exit. The feedback highlights two key improvements: snapshotting the keys of processGroupsByThread before iterating to prevent issues when mutating the Map during iteration, and properly catching and logging errors from prepareApplication during boot to avoid silent failures and potential crashes when accessing untrusted error properties.

[claude]

Reviewed; no blockers found.

[kriszyp]

Final self-review identified two implementation hardening items, addressed in 07a6de1, plus one separate cross-node deployment-ordering concern that requires its own protocol rather than widening the local install mutex.

[kriszyp]

Final lock audit findings addressed in 59d4cc3: immutable bakery tickets remove stale-owner CAS races, process-start identity handles PID reuse, and Windows distinguishes taskkill failure from an independently confirmed dead tree.

[Ethan-Arrowood]

Approving — the bakery-lock serialization is solid and fully supported by tests, and everything stays on the cold install path. Leaving a few non-blocking findings inline: two edge-case gaps around stale-owner/orphan handling worth a follow-up, and two smaller cleanups.

Also: the deferred deploy-transaction ordering issue raised in-thread is real and well-characterized now — please file a tracking issue before this merges so it doesn't evaporate.

_{sent with Claude Fable 5}

[kriszyp]

🤖 Note on 3 missing review threads: while clearing pending review state on this PR I deleted a pending (unsubmitted) self-review that, on closer inspection, actually contained 3 live inline comments — not stale draft text as its summary body suggested. Recreating them here since GitHub doesn't let me restore the original threads:

components/Application.ts (~L1771) — "Could we avoid using the direct child's exit state as proof that the whole POSIX process group is gone? A custom installer can spawn and unref a descendant that inherits stdout/stderr, then exit. At timeout exitCode is already set while process.kill(-pid, 0) still succeeds; this branch waits five seconds, destroys the pipes, rejects, and lets prepareApplication release the component lock while that descendant can keep mutating node_modules. Please probe/terminate the process group even when the direct child has exited, and add a regression where the parent exits before timeout but its child continues writing."
→ Addressed in ff613c8: terminateProcessTree now probes the process group itself instead of trusting the direct child's exitCode/signalCode.

server/threads/manageThreads.js (~L903) — "Please keep a dead worker's preparation claim non-reclaimable until its tracked process groups are confirmed gone. process.kill(..., 'SIGKILL') queues the signal and returns; immediately afterward isThreadRunning() reports false, so another contender can delete the worker's ticket and enter preparation before termination has been observed. That reopens the concurrent-writer window this PR is intended to close. Please coordinate process-group termination state with owner liveness (or otherwise delay reclamation until the group no longer exists), and test that a replacement preparation cannot enter until the old writer has stopped."
→ Addressed in ff613c8: a dead worker's lock claim is no longer reclaimable until its tracked process groups are confirmed terminated, including a Linux zombie-state check so a group whose owning worker's event loop is gone doesn't wedge reclamation forever.

DESIGN.md (~L130) — "Small documentation drift from the latest reclamation rewrite: publishClaim() now publishes the completed record with rename(), not a hard link. Could we update this sentence so the design note matches the implementation?"
→ Addressed in ff613c8: DESIGN.md now says rename().

All three were already fixed before I found the deletion mistake; only the GitHub thread objects themselves are unrecoverable, not the underlying findings or their resolution.

[kriszyp]

Filed #1996 to track the cross-node deploy-transaction ordering gap (config write → install → replication not serialized across concurrent same-component deploys) per @Ethan-Arrowood's request — scoped separately from this PR's node_modules corruption fix (#1973).

All other inline review threads are resolved (including the 3 recreated ones from the earlier pending-review mishap). No other open review feedback found.

🤖 KrAIs (Claude)