fix: release per-key coalescing lock when RTCache writer is cancelled

[stareezy-1]

Summary

Fixes #931

Problem

RTCache::get() inserts a zero-permit CacheLock into lockers on a cache miss, then awaits the user-provided Lookup::lookup() callback. The lock was only released and removed after the lookup completed:

let value = CB::lookup(key, extra).await;   // cancellation point
// ... cleanup below never runs if this future is dropped
my_write.lock.add_permits(10);
lockers.remove(&hashed_key);

If the get() future is cancelled while the callback is pending (timeout, losing select! branch, task abort, runtime shutdown), the lock stays installed with zero permits and no live owner. Later same-key requests then:

• block forever with lock_age = None / lock_timeout = None (per-key liveness failure), or
• repeatedly bypass normal coalescing / cache insertion with lock_timeout / lock_age set.

Fix

Introduce a WriterLockGuard that owns the inserted lock entry:

• On drop — including cancellation of the writer future — it wakes waiters (add_permits) and removes the lock from lockers.
• Removal is guarded by an Arc identity check so a cancelled old writer never deletes a newer writer's lock.
• The normal completion path now relies on the same guard's drop, so there is exactly one cleanup path.

lockers becomes Arc<RwLock<...>> so the guard can reach it without borrowing the cache.

Tests

test_cancelled_lookup_releases_coalescing_lock (inverted from the issue's whitebox repro):

Step	Verifies
Writer enters lookup() then is aborted	cancellation window reachable
lockers no longer contains the key	cancelled writer removes its lock — fails without the fix
Next same-key get() completes with a fresh lookup	bounded progress; second call becomes the new writer

Full crate suite passes (cargo test -p pingora-memory-cache), cargo fmt --check and clippy clean.