Claude review: rust: drm: gem: Add vmap functions to shmem bindings

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

Patch Review

This is the largest patch and adds the core vmap functionality. The design is well thought out.

**`make_vmap` guard lifetime**: The explicit `drop(guard)` before the iomem error path is correct — `raw_vunmap` re-acquires the lock internally:
```rust
let guard = DmaResvGuard::new(self);
to_result(unsafe {
    bindings::drm_gem_shmem_vmap_locked(self.as_raw_shmem(), map.as_mut_ptr())
})?;
drop(guard);
```
Good defensive pattern.

**VMap::Drop reconstruction**: The `drop` reconstructs an `iosys_map` to pass to `raw_vunmap`:
```rust
self.owner.raw_vunmap(bindings::iosys_map {
    is_iomem: false,
    __bindgen_anon_1: bindings::iosys_map__bindgen_ty_1 { vaddr: self.addr },
})
```
This works because `make_vmap` already validated `!is_iomem` before constructing the `VMap`. The invariant is maintained.

**IoCapable implementations**: The `impl_vmap_io_capable!` macro implements `ptr::read`/`ptr::write` through raw pointer casts:
```rust
unsafe fn io_read(&self, address: usize) -> $ty {
    let ptr = address as *mut $ty;
    unsafe { ptr::read(ptr) }
}
```
The safety is delegated to the `Io` trait's `io_read`/`io_write` contract (alignment, bounds). This is correct.

**Minor**: The `VMap` struct's `addr` field is `*mut c_void` — this raw pointer doesn't implement `Send`/`Sync`, but `VMap` doesn't explicitly implement them either. Since the GEM object backing the mapping is thread-safe, and the mapping itself is valid for the lifetime of the owner, this might need explicit `Send`/`Sync` impls if callers need to share the mapping across threads. However, this may be intentionally restrictive for now.

**Tests**: Good coverage — `compile_time_vmap_sizes` validates the size check and `vmap_io` tests read/write through the mapping. The byte-level verification of a `write32` is a nice touch.

---
Generated by Claude Code Patch Reviewer