break_lock_file renames a lock it judged stale aside and then re-checks
only the modification time before unlinking it, but on a filesystem with
coarse mtime granularity like nfs or fat a peer can break and recreate
the lock within the same second, so the live recreation carries the same
mtime the waiter saw and gets unlinked, letting a second process acquire
it. the sibling marker break in _soft_rw already re-verifies the marker
token for exactly this reason, so this captures the inode at the stale
decision and aborts the break when the renamed file's inode no longer
matches. i added a regression test that recreates the lock with a fresh
inode under an identical mtime, which unlinks the live file before this
change and leaves it untouched after.

SoftReadWriteLock._refresh_marker only catches FileNotFoundError around
its heartbeat touch, so a transient ESTALE or EIO (routine on the
NFS-style filesystems this lock is meant for) escapes as an unhandled
OSError and kills the heartbeat thread without ever setting
heartbeat_stop. The holder still believes it holds the lock while the
marker stops being refreshed, so it goes stale, a peer evicts it and
acquires, and two processes end up holding conflicting locks. The
writer-drain touch in readers_drained_touching already wraps the same
call in suppress(OSError), so this just brings the heartbeat into line:
a transient touch error is swallowed and retried on the next tick, since
the read just above has already confirmed the marker is still ours and a
genuinely vanished marker is caught by the next iteration's
_read_marker.

---------

Co-authored-by: Bernát Gábor <[email protected]>