[thorwhalen]

Closes #163. Adds dol.file_lock(path) (one-off context manager, yields whether the lock is held) and dol.FileLock (reusable, keeps its handle) in dol/atomic.py. Additive; no new dependency.

Behaviour (from xdol#23): fork-safe (pid check, reopen; thread lock renewed in the child), Windows polls LK_NBLCK instead of LK_LOCK, read-only lock file falls back to a read-only open, unsupported filesystems / unopenable lock file run the body with held=False. Threads of one process exclude each other too.

Not included: the optional "appender that follows an atomically replaced file" (stays in xdol; follow-up issue).

Tests: multi-process, threads, fork inheritance, read-only lock file, release on exception, doctests.

Adversarial review (Opus, two rounds)

Round 1 found: a forked child leaving the with released the parent's lock; the multiprocess test was vacuous (O_APPEND is atomic anyway); sidecar="" swapped the locked inode under atomic_write; open failures were swallowed; same-thread nesting deadlocked; unclosed handles. Round 2 found the fork hook's fresh thread lock made the child's __exit__ raise, finalizer pile-up, close() inside the block deadlocking.
Fixed: child __exit__ is a no-op; multiprocess test is now a read-modify-write counter; sidecar must be non-empty; only read-only/permission cases degrade to held=False, anything else raises; reentry and in-block close() raise; one finalizer; defaults hoisted to constants. Not changed: NFS per-process fcntl semantics (two locks in one process don't exclude on NFS) is inherent to flock emulation. Verdict after fixes: merge.