fix(acquire_lock): stale-lock threshold equals wait timeout — live holder lock stolen mid-mirror

## Summary
In lib.sh::acquire_lock_with_recovery (line 1086) the staleness check is 'if [ "${_alwr_age}" -le "${_alwr_timeout}" ]; then ... respect'. The sentinel timestamp is written once (lib.sh:983) and never refreshed, so a mirror that legitimately runs longer than concurrency_lock_timeout (default 300 s — routine for a large site; LFTP_TIMEOUT is 5 h) is indistinguishable from a dead holder. Runner B deletes A lock and starts mirroring concurrently; when A finishes, its trap RMDs the lock dir now owned by B, so C enters too — the failure cascades rather than self-corrects.

## Suggested fix
Decouple staleness from the wait window, e.g. add concurrency_lock_stale_after (default > LFTP_TIMEOUT) and compare against that, or refresh the sentinel periodically.

## Source
F2 audit round (post-v2.11.3 release).

Start in lib.sh at acquire_lock_with_recovery around line 1086, then inspect the sentinel timestamp written around line 983 and the lock cleanup path. Trace how the wait timeout and sentinel age interact during a mirror longer than 300 seconds. Done means a live holder is not treated as stale, and its cleanup cannot remove a lock directory now owned by another runner.

Vom Indexierungsmodell aus dem Issue-Text verfasst.