concurrency.ResumeMutex

### What would you like to be added?

`concurrency.Election` has `ResumeElection`, for reconstructing an election handle after
a process restart (paired with `Session`'s `WithLease` option for a surviving lease).
`concurrency.Mutex` has no equivalent -- a restarted process that was holding a lock has
no way to get a working `*Mutex` handle back for it; it can only start over with a fresh
`Lock()` call, losing the distinction between "I already own this lock" and "I need to
compete for it."

I verified this actually works by writing `ResumeMutex` and a real integration test that
simulates the restart scenario (reconstructing a Mutex purely from a session + the
previously-written key + its revision) -- `IsOwner()` correctly recognizes the resumed
handle as the owner, and `Unlock()` through it correctly deletes the real server-side key.

### Why is this needed?

Mutex's `myKey`/`myRev` fields are structurally identical to Election's `leaderKey`/
`leaderRev`, and `IsOwner()`/`Unlock()` only depend on those two values being set
correctly -- they have no dependency on which constructor produced them. This is a small,
mechanical port of a pattern that already exists and is already proven for Election.

Opening a PR with the implementation: [will link after PR is created]

Compare concurrency.Election's ResumeElection with the Mutex implementation, focusing on the myKey/myRev and leaderKey/leaderRev state used by IsOwner() and Unlock(). Review the existing restart integration test described in the issue and verify that a resumed Mutex recognizes ownership and can unlock the server-side key; completion includes the API and corresponding test.

Written by the indexing model from the issue text.