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 mechanical extraction of the boot code into a HAL trait pattern. The existing `run_fwsec_frts` and boot-related logic moves from `gsp/boot.rs` into `gsp/hal/tu102.rs`, with a trait `GspHal` defined in `gsp/hal.rs` and a stub `Gh100` HAL.

**Observations:**

1. The HAL dispatch is a static function returning `&'static dyn GspHal`:
```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
        }
    }
}
```
This is clean — the match is exhaustive, the static dispatch avoids allocations, and the `dyn GspHal` provides the needed polymorphism. The `Send` bound on the trait is appropriate since the HAL instances are `&'static`.

2. The `post_boot` trait method has a default no-op implementation, which makes sense since GH100 doesn't need sequencer logic. Good trait design.

3. The `boot` method in `tu102.rs` takes `gsp: &Gsp` (versus `self: Pin<&mut Self>` in the original). This works because the HAL implementation accesses `gsp.libos` and `gsp.cmdq` through shared references, and those fields provide interior mutability where needed.

4. The `#[allow(clippy::too_many_arguments)]` on the trait method is pragmatic — the parameters are all genuinely needed. No concern here.

5. Minor: in `gsp/boot.rs` the call passes `&self` to `hal.boot()`:
```rust
hal.boot(
    &self,
    dev,
    ...
```
This is fine because `self` here is `Pin<&mut Gsp>` and `&self` reborrrows as `&Gsp`, which is what the HAL expects.

**No issues.** This is a clean mechanical refactoring.

---

---
Generated by Claude Code Patch Reviewer