fix(update): GUI update self-deadlocks against its own lock — every retry fails with "Hermes is still running"

[OutThisLife]

Any install whose checkout already carries the cross-process update lock (fe8e4d9, merged yesterday) self-deadlocks on its next GUI → Update Hermes: the Tauri updater claims the update-in-progress marker for its whole run, then spawns hermes update as a child stage — which reads the marker, finds its own parent's live pid, and refuses with exit 2. The GUI surfaces that as "Hermes is still running. Close all Hermes windows and try the update again", and Retry launches a fresh updater that deadlocks against itself the same way.

The rollout shape hides it for one cycle: the child checks the lock from disk code before pulling, so the first update after fe8e4d9 landed still runs the pre-lock child and succeeds — it's the update after that which dead-ends. Observed exactly that way in bootstrap-installer.log: a clean update at 04:44 UTC (the one that installed the lock code), then three consecutive self-refusals (PIDs 86193 → 86854 → 87252) starting 05:42, each refusing its own parent's marker.

The fix hands the claim off explicitly instead of weakening the lock: update_child_env exports HERMES_UPDATE_HANDOFF_PID naming the updater's own pid, and UpdateLock.acquire treats a live holder matching that pid as the lock we're already running under — the child runs without claiming, and release leaves the parent's marker untouched for the remaining rebuild/install stages. The env var alone grants nothing: the pid must also be the live marker's owner, so a stale or forged value can't bypass the lock, and a dashboard-spawned hermes update (no handoff env) is still refused exactly as the original fix intended.

[github-actions]

૮ >ﻌ< ა ci review

_{ran on 8c76fe1}

ℹ️ Info

Desktop E2E visual evidence · View test artifacts · View job

1 visual diff.

_{inline evidence is publishing...}