fix(server): retry the create after reclaiming a confirmed stale lock

Macroscope on the previous commit: reclaiming a dead lock returned
ServerLockUnavailableError even with no competing starter, so the first
restart after a crash failed instead of claiming the freed directory; and a
shutdown racing readHolder to remove the lock sent fs.utimes a NotFound that
failed the starter outright.

A confirmed-dead reclaim now retries the exclusive create on the next pass, so
a clean restart after a crash claims its directory in one call. The retry is
still bounded — MAX_RECLAIM_CYCLES — so a lock another starter keeps
recreating, or a permissions wall keeps failing to remove, surfaces as
ServerLockUnavailableError rather than spinning. Both refresh paths tolerate
NotFound between the read and the utimes, which closes the shutdown race; the
two paths shared a tail and now use one branch.

Verified: serverSingleton suite 14/14, typecheck exit 0.
5dd4ca7ff3NoahLinckeScout committed on 9/14/2026, 8:27:20 PMparent68697eb
2 files changedLine totals unavailable