dev: close the shared Maka Dev profile launch race (atomic reservation / ownership handshake)

[Astro-Han]

Follow-up to #3359 (shared 'Maka Dev' profile owner gate).

The owner gate reads a process snapshot via pgrep/ps; the single-instance lock is taken by Electron at spawn time, AFTER the gate. Two worktrees launching nearly simultaneously can both pass the gate; the loser is focused onto the winner's window or lands on never-started.

Closing the window needs one of:

• a profile-level atomic reservation (reserve the userData lock before spawn, release on handoff/failure), or
• a post-spawn ownership handshake (after spawn, verify the running instance is the one we started; if not, surface the actual owner).

Documented in apps/desktop/README.md (owner gate section).

[Astro-Han]

Notes from the #3359 review, recorded here so the dead ends are not re-walked. Nothing below changes the scope of #3359 itself — that PR now consumes the real single-instance result and stops there.

Why the launcher layer cannot own this

Three designs were tried and each was ruled out on evidence:

1. A time threshold ("process visible for N ms without the lock ⇒ it lost") has no correctness upper bound. requestSingleInstanceLock() runs after Electron/Node startup, dependency loading and log installation; a cold disk, CPU contention or a suspended process can exceed any fixed window. A threshold only moves the misjudgment line, it is not a criterion.
2. Inferring from process visibility does not work, because the losing process is itself visible: it really starts, and only then fails the lock.
3. A launcher-level profile reservation is not on all entry points — Dock, Spotlight and Screen Recording's "Quit & Reopen" have no launcher at all — and a Unix-domain-socket handoff is not atomic across unlink/rebind.

The general form: the authority has to live where the lock is. Reconstructing "who owns this data directory" from a flattened ps command line is not a faithful mapping — the TCC profile is not on the command line at all (it is read from dev-env.json, a mutable file), plain values contain spaces, the npm shim's argv[0] is node, and helper/GPU/about-to-exit processes all match pgrep -f.

If we ever want to name the owner

The right primitive is the record the lock itself writes, not a guess from argv.

Verified against the exact versions this repo pins (Electron 43.2.0 → Chromium 150.0.7871.129):

• Chromium keeps a SingletonLock symlink under the user-data dir, pointing at a non-existent target whose name is hostname-pid.
• Create() writes that symlink; Cleanup() unlinks lock/socket/cookie.
• The recovery path resolves the hostname/PID and, if the PID does not exist or is not a Chrome process, removes the orphaned lock and continues.

Sources: Electron 43.2.0 release · process_singleton_posix.cc @ 150.0.7871.129

Consequences for any future implementation:

• A stale symlink may be ignored; "the PID is still alive" is the condition that should block.
• A hostname from another machine must not be treated as a live local PID.
• Not verified: after a SIGKILL the holder never gets to run Cleanup(), so whether a stale symlink is left behind is an inference, not a tested fact. It needs a real-machine check before anything relies on it.

Any such gate should also run after the launcher reclaims its own stale processes, and should degrade to a generic conflict message on any inconsistency rather than blocking.

Separate, pre-existing behaviour found while reviewing #3359

A dev instance whose main process is blocked can be SIGKILLed by the next launch.

requestSingleInstanceLock() calls Chromium's NotifyOtherProcessOrCreate(), which passes kill_unresponsive=true. The lock holder only ACKs after its notification callback has run on the UI thread, so a main process that is blocked (busy loop, debugger breakpoint, or otherwise not turning its event loop) cannot ACK. After 20 seconds the new instance kills the holder with SIGKILL and takes the lock itself.

Reproduced on macOS with Electron 43.2.0: the hung holder was killed and the second instance reported lock=true after 20023 ms — i.e. it becomes the winner, not a loser, so none of the loser-reporting paths ever run and the terminal shows nothing unusual. Unsaved state in the killed instance is lost.

This is not introduced by #3359. On its merge base, plain npm run dev already used the shared Maka Dev profile (main.ts, app.setName) while only the TCC bundle was worktree-scoped, so plain↔plain across worktrees could already race. Sharing the profile widens which pairs can collide (now plain↔TCC and TCC↔TCC as well); it does not create the behaviour.

Reproduction boundary, stated explicitly: the repro used a busy loop and plain Electron. A debugger breakpoint and the TCC bundle were not tested — the mechanism lives in Chromium and is expected to be identical, but that expectation is an inference.

Note on this issue's title

The title still says "atomic reservation / ownership handshake". The reservation direction is the one ruled out above; if this issue stays open, its scope is better described as "name the conflicting owner from the lock's own record, after the fact".