Fix unsafe time.Timer.Reset on active timers in runlock and filelock

Both filelock.AcquireExclusive and askcli.waitOrAcquireAskLockFD created a
single time.Timer and called Reset() on it each retry iteration before it had
necessarily fired. Per the Go timer API, Reset()-ing a timer that may still be
pending is unsafe: a stale value can already be queued on the channel, causing
a spurious early wake-up.

Replace the reused-timer + Reset() pattern with a fresh time.After(...) per
loop iteration, which guarantees a clean full retry interval (or context
cancellation) every time and removes the reuse-while-active hazard. Dropped the
now-unused *time.Timer parameter from waitOrAcquireAskLockFD and introduced
named retry-interval constants.

Add a context-cancel-while-blocked test for the runlock retry loop.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions