fix(code): serialize dcode self-upgrades across processes

[Mason Daugherty (mdrxy)]

Closes #5250

When several dcode terminals are open at once, only one of them installs an update now — the others keep running the version they launched with and pick up the new one next launch.

---

Nothing coordinated the startup auto-update across processes. Every launching terminal independently decided an update was available and ran its own uv tool install -U against the same tool environment. The only lock in the area, _environment_mutation_lock, is an in-process asyncio.Lock.

Two things partly hid this, neither of which is a lock. A terminal opened after another finished upgrading self-skips, because is_installed_version_at_least reads the on-disk distribution metadata — that covers "open a new tab later" but not "open four tabs at once". And uv takes its own lock on the tool directory, so concurrent installs queue rather than corrupt; but they wait, and a queued loser can exceed the upgrade timeout, be reported to the user as Auto-update failed, and write a 24-hour cooldown suppressing its next legitimate attempts. Upgrading in place is also actively hostile to running sessions: _prewarm_deferred_imports already carries a defensive guard because a concurrent upgrade can make a not-yet-imported module transiently absent and crash the TUI.

update_install_lock is a non-blocking context manager pairing a process-local threading.Lock with a FileLock(thread_local=False) on a dedicated lock file in the state directory — the same shape as _approval_state_lock and _trust_store_lock, so no new dependency. It yields whether the caller may install; losers return immediately rather than stalling startup behind an install they do not need, and record no failure cooldown, since nothing failed. It is taken by all three paths that replace the installed package: startup auto-update, /update, and the update notification's install action.

Test plan

• update_install_lock exclusion is tested against a real second OS process holding the same lock file, not a patched filelock.
• Covers release on normal exit, release after an exception, refusal of a second in-process holder, the fail-open path, the startup skip recording no cooldown, lock release before the re-exec, and the two app-level install paths deferring and releasing.
• The unit-test state-dir isolation fixture now redirects the lock file, so no test can contend with a genuinely running dcode.

Made by Open SWE