Try to claim the exclusive right to self-upgrade dcode.
Startup auto-update, dcode update, /update, and the update notification
all replace the same installed package, so concurrently launched terminals
would otherwise each run their own install against one tool environment.
Whichever process wins the lock performs the upgrade; the rest keep running
the version they launched with and pick the new one up on their next launch.
Non-blocking by design: a loser returns immediately rather than stalling startup behind an install it does not need.
If a legacy directory exists, hold its lock alongside the current lock for the entire install, creating the file if necessary: older sessions may attempt their first update after we acquire the current lock. Keep its inode after release so those sessions always contend on the same file. An older process that creates a legacy directory later cannot share this protection.
The locking itself never raises; exceptions from the caller's own body
propagate as usual. When the lock is unusable — an unwritable state
directory, or a filesystem whose locking the OS refuses — this yields
True and lets the caller proceed unsynchronized. That is the behavior
from before this lock existed, and it is the fail-open choice: yielding
False there would mean updates never run again on that machine. Only a
lock genuinely held elsewhere yields False.
