Claude review: gpu: nova-core: gsp: move chipset-specific parts of the boot process into a HAL

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

Patch Review

This is a large mechanical extraction. The key design decisions:

**GspHal trait:**
```rust
pub(super) trait GspHal: Send {
    fn boot(&self, gsp: Pin<&mut Gsp>, ...) -> Result;
    fn post_boot(&self, ...) -> Result { Ok(()) }
}
```

The `post_boot` has a default no-op implementation, which is clean. The `boot` method takes `Pin<&mut Gsp>` which is needed to access `gsp.libos.dma_handle()`.

**HAL dispatch:**
```rust
pub(super) fn gsp_hal(chipset: Chipset) -> &'static dyn GspHal {
    match chipset.arch() {
        Architecture::Turing | Architecture::Ampere | Architecture::Ada => tu102::TU102_HAL,
        Architecture::Hopper | Architecture::BlackwellGB10x | Architecture::BlackwellGB20x => {
            gh100::GH100_HAL,
        }
    }
}
```

Using `&'static dyn GspHal` avoids allocation. The `const` instances (`TU102` and `GH100`) are zero-sized types, so this is effectively free.

**GH100 stub** returns `Err(ENOTSUPP)` — this replaces the previous `Architecture` match guard in `boot()`. Functionally equivalent.

**Boot method signature change:** `self: Pin<&mut Self>` → `mut self: Pin<&mut Self>`. The `mut` is needed because `self.as_mut()` is called. This is correct.

**`#[allow(clippy::too_many_arguments)]`** on the `boot` trait method — 8 arguments is indeed a lot. A boot context struct could reduce this, but that's a future improvement. The allow is pragmatic.

**One concern:** In `tu102.rs`, the `post_boot` accesses `gsp.libos` and `gsp.cmdq` directly:
```rust
        let seq_params = GspSequencerParams {
            ...
            libos_dma_handle: gsp.libos.dma_handle(),
            ...
        };
        GspSequencer::run(&gsp.cmdq, seq_params)?;
```
This works because `gsp` is `Pin<&mut Gsp>` and these fields are not pinned (only `logs` and `cmdq` are pinned). Accessing `cmdq` through a `Pin<&mut>` reference should be fine since `Cmdq` likely implements `Unpin` or the access is via shared reference. This looks correct.

No blocking issues. The extraction is mechanical and faithful.

---

---
Generated by Claude Code Patch Reviewer