feat: add distributed Locker client (rueidislock port)

[gtoxlili]

This PR adds a clients::Locker interface modelled on
Go's rueidislock.
It uses RESP3 client-side-cache invalidation pushes so a holder learns about
takeovers and evictions the moment they happen, plus a background extender that
bumps PEXPIREAT on a cadence (default validity / 2).

Public surface

let locker = Builder::default_centralized().build_locker(LockerConfig::new())?;
locker.client().init().await?;
locker.init().await?;

let guard = locker.acquire("cron:purge").await?;
tokio::select! {
    _ = do_work() => {}
    _ = guard.cancelled() => {} // someone else took the lock
}
guard.release().await;

What's in

• Locker + LockGuard + LockerConfig behind a new locker feature flag
  (pulls in i-keys, i-scripts, i-tracking, sha-1).
• Builder::build_locker for the standard entry point.
• on_reconnect hook that re-arms CLIENT TRACKING — fred doesn't restore it
  automatically and without this every connection bounce would silently drop
  invalidation pushes for active holders.
• Weak<LockerInner> in the dispatcher + reconnect handler so neither task
  keeps the locker alive after the last Locker clone drops; Drop for LockerInner aborts both for prompt cleanup.
• Six Lua scripts mirroring rueidislock (acqat / acqms / fcqat / fcqms
  / extend / delkey), each with the trailing GET that arms tracking on
  the lock key.
• Race-free Notify usage: Cancellation::cancelled pins the Notified and
  calls enable() before the second flag check; per-gate signals use
  notify_one (matching rueidislock's buffered chan size=1).
• init() serializes concurrent callers via an async mutex and only publishes
  initialized = true after every fallible step succeeds, so a failed init is
  retryable and a race cannot spawn duplicate dispatchers.
• register_outstanding and close are serialized through the same mutex, so
  an acquire racing with close either gets registered (and promptly cancelled)
  or refuses to register and runs a CAS-delete on the key it just wrote — no
  stranded keys.
• Integration tests in both centralized and clustered harnesses: acquire /
  release, contention, in-process waiting, auto-extension past validity,
  force-takeover detection via push, tracking re-arm after force_reconnection,
  close-cancels-outstanding-guards.

What's not (out of scope, follow-ups)

• Multi-key Redlock (KeyMajority > 1). The config shape leaves room for
  LockerConfig::key_majority(n) without breaking changes.
• Connection-affinity guarantee equivalent to rueidis's PipelineMultiplex = -1. fred's start_tracking broadcasts and EVAL routes per-key, so for
  single-key locks this works in practice, but a multi-key variant would need
  extra care.
• metrics / mocks integration — rueidislock doesn't ship those either.

Happy to split this into smaller pieces if that would help review.