Claude review: gpu: nova-core: send UNLOADING_GUEST_DRIVER GSP command upon unloading

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

Patch Review

**Status: Mostly good, a couple of observations**

This is the core functional patch. It adds:

1. A `PowerStateLevel` enum for the unload power state.
2. The `UnloadingGuestDriver` command (both fw-level and GSP-level wrappers).
3. `shutdown_gsp()` which sends the command then polls mailbox0 for the suspended bit.
4. `unload()` method on `Gsp` that calls `shutdown_gsp()`.

**Observations:**

The `#[expect(unused)]` on `PowerStateLevel` is appropriate since only `Level0` is currently used; `Level3` and `Level7` are needed for future suspend/hibernate support.

The `shutdown_gsp` polling logic:

```rust
const LIBOS_INTERRUPT_PROCESSOR_SUSPENDED: u32 = bits::bit_u32(31);
read_poll_timeout(
    || Ok(gsp_falcon.read_mailbox0(bar)),
    |&mb0| mb0 & LIBOS_INTERRUPT_PROCESSOR_SUSPENDED != 0,
    Delta::from_millis(10),
    Delta::from_secs(5),
)
.map(|_| ())
```

This correctly checks bit 31 (per the v3 changelog fix) with a 5-second timeout and 10ms polling interval, which seems reasonable.

The `UnloadingGuestDriverReply` uses `type Message = ()` which means the reply content is ignored — this is fine if the GSP reply to this command carries no meaningful payload.

Minor: the `UnloadingGuestDriver` wrapper in `commands.rs` has the same name as the fw-level type in `fw::commands::UnloadingGuestDriver`. This is exactly the naming collision that patch 4 prepared for, and it works cleanly with the qualified paths.

The `AsBytes` safety comment for `UnloadingGuestDriver` says "Padding is explicit and will not contain uninitialized data" — I verified the binding struct does have explicit `__bindgen_padding_0: [u8; 2usize]`, and the `new()` uses `..Zeroable::zeroed()` which zero-initializes the padding. This is correct.

---
Generated by Claude Code Patch Reviewer