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.
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.
