#2659 acquireModelLocks writes SWAMP_LOCK_HOLDER_PID to process-global env, so concurrent runs in one process clobber each other

Problem

acquireModelLocks (src/cli/repo_context.ts:1721) calls Deno.env.set for SWAMP_LOCK_HOLDER_PID with the current pid, and its flush callback (:1725) deletes it. The variable tells child swamp processes (which inherit env) to skip waiting on the parent's own per-model locks (read in waitForPerModelLocks, repo_context.ts:1331).

The env is process-global. In a long-lived swamp serve, several workflow and model runs acquire locks concurrently (serve/deps.ts:356, serve/handlers/model_handlers.ts:211 and :452). When run A finishes and flushes, it deletes the variable while run B still holds its locks. Any child swamp process that run B spawns after that point no longer sees the variable, so it waits on run B's lock until the lock timeout.

The same write races across parallel unit test files, since they share one process env (found while triaging swamp-club#2658).

Expected

The lock-holder marker should be scoped to the run that holds the locks. For example, inject a store the way ProcessTraceEnv does (src/domain/models/process_trace_env.ts, TraceEnvStore), or pass the marker explicitly in the child process env, rather than mutating Deno.env for the whole process.