Hold a lock so a second scan fails at once (closes #53)

scan takes an exclusive flock(2) on a lock file beside the database
(its path with .lock appended) before it walks anything or opens the
database, and holds it until it returns. A second scan against the
same database fails at once with a one-line error naming the lock
file and exits 1. report and trees never take the lock. The lock ends
with the process, so a fatal error or an interrupt releases it; the
file is never deleted. golang.org/x/sys becomes a direct dependency.

The README smoke test now keeps the database outside the scanned
tree, where its empty lock file would have joined the empty-file
group.

Model: opus-5-5

TODO.md

@@ -29,6 +29,10 @@
 
 # Completed Steps
 
+- `scan` holds a lock on a lock file beside the database for its whole run,
+  so a second `scan` fails at once with exit 1 (2026-10-03,
+  https://git.eeqj.de/sneak/sfdupes/issues/53)
+
 - test stdout write failures in `report` and `trees`; README states that
   `| head` ends sfdupes by `SIGPIPE` and `>&-` writes to `/dev/null`
   (2026-10-03, https://git.eeqj.de/sneak/sfdupes/issues/30)