Claude review: rust: sync: lock: Add Lock::get_mut_pinned()

[Claude Code Review Bot <claude-review@example.com>]

Patch Review

This patch adds a method to `Lock` that provides `Pin<&mut T>` access when you hold a `Pin<&mut Lock<...>>`, bypassing the actual locking since `&mut` guarantees exclusivity at compile time. This mirrors `std::sync::Mutex::get_mut()`.

**Correctness**: The implementation is sound. `Lock::data` is declared as `#[pin] pub(crate) data: UnsafeCell<T>` (lock.rs:118-119), so `T` is structurally pinned within the `Lock`. Having `Pin<&mut Self>` guarantees exclusive access, and returning `Pin<&mut T>` preserves the pin projection correctly. The `map_unchecked_mut` + `UnsafeCell::get_mut` path is the standard pattern.

**Minor items**:

1. The SAFETY comment is slightly sparse:
```rust
// SAFETY: We return a pinned T, ensuring we don't move T.
unsafe { self.map_unchecked_mut(|data| data.data.get_mut()) }
```
It would be more precise to note *why* this is a valid pin projection — i.e., that `data` is structurally pinned within `Lock` (via `#[pin]` on the field). The current comment explains the output constraint (we don't move T) but not the input justification (the field is structurally pinned). This is minor since the `#[pin]` attribute is visible on the struct definition.

2. The `#[inline(always)]` is arguably aggressive for a method that will likely only be called in `Drop` paths and similar low-frequency situations. `#[inline]` would be sufficient, consistent with the existing `lock()` and `try_lock()` methods in the same `impl` block.

3. The commit message references "These two functions" (plural), but only one function is added. Looks like the commit message may have been written when a non-pinned `get_mut()` was also planned.

**Verdict**: Good. The approach is correct and matches standard Rust practice.

---

---
Generated by Claude Code Patch Reviewer