[ISSUE #10065] Fix inconsistent lock/unlock timeout and improve expired lock handling in ReceiptHandleGroup

[Wubabalala]

Summary

ReceiptHandleGroup.HandleData uses different timeout multipliers for lock() (*3) and unlock() (*2), creating a deadlock window of duration T in the range [2T, 3T):

1. Thread A holds the lock longer than 2T (e.g., slow network I/O)
2. Thread A calls unlock() — since elapsed > T*2, it skips semaphore.release(), leaking the permit
3. Thread B calls lock() — tryAcquire() fails (0 permits), and force-acquire requires elapsed > T*3, which isn't met yet
4. All operations on the affected HandleData throw ProxyException(INTERNAL_SERVER_ERROR) until 3T elapses

With the default lockTimeoutMsInHandleGroup = 3000ms, this is a 3-second window where the semaphore is stuck.

Changes

• Align unlock() threshold from *2 to *3 to match lock()'s force-acquire threshold, eliminating the gap
• Check lock expiry before tryAcquire() so that expired locks are force-acquired immediately without blocking for the full timeout (addresses the second point in the issue)
• Extract tryForceAcquire() to deduplicate the double-checked locking block between the fast path and slow path
• Add two tests covering the aligned threshold behavior and the pre-check fast path, verified to fail on the old code

Test plan

• testUnlockReleasesWithinAlignedThreshold — verifies semaphore is properly released when elapsed is in [2T, 3T) (failed with old *2 threshold)
• testLockForceAcquiresBeforeTryAcquire — verifies expired lock is force-acquired in <50ms instead of blocking for the full timeout (old code: 111ms; new code: <5ms)
• All 7 existing ReceiptHandleGroupTest tests pass (no regression)

Fixes #10065