Claude review: rust/drm: Don't setup private driver data until registration

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

Patch Review

**Critical concern — error path for data initialization failure:**
```rust
fn new(
    drm: drm::UnregisteredDevice<T>,
    data: impl PinInit<T::Data, Error>,
    flags: usize,
) -> Result<Self> {
    unsafe { data.__pinned_init(drm.0.data.get().cast()) }?;
    drm.data_is_init.store(true, Ordering::Relaxed);
    to_result(unsafe { bindings::drm_dev_register(drm.as_raw(), flags) })?;
```

If `data.__pinned_init()` succeeds but `drm_dev_register()` fails, the function returns `Err`, which drops `drm` (the `UnregisteredDevice`). This will eventually call `release()`, which checks `data_is_init` and will drop the initialized data — so this is correct.

However, if `data.__pinned_init()` itself fails, the `?` propagates the error and `drm` is dropped. At this point `data_is_init` is still `false`, so the data won't be double-dropped. But we need to verify that the partially-initialized data from a failed `__pinned_init` is properly handled. By the `PinInit` contract, if `__pinned_init` returns an error, the memory is left in a valid-to-deallocate state (i.e., not needing drop). So this is fine.

**`pub(super)` on `UnregisteredDevice` tuple field:**
```rust
pub struct UnregisteredDevice<T: drm::Driver>(pub(super) ARef<Device<T, Uninit>>, NotThreadSafe);
```
Making the inner `ARef` `pub(super)` is needed for the `drm.0.data.get().cast()` access in `driver.rs`. This is acceptable since both files are in the `drm` module, but it does weaken the encapsulation of `UnregisteredDevice`.

---
Generated by Claude Code Patch Reviewer