Claude review: gpu: nova-core: firmware: fix and explain v2 header offsets computations

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

Patch Review

This is an important correctness fix. The old code set both secure and non-secure IMEM `src_start` to `0`, which is incorrect — they can't both start at offset 0 in the firmware blob.

The fix correctly computes the secure IMEM offset:
```rust
let imem_sec_start = self.imem_sec_base.saturating_sub(self.imem_virt_base);
```

**`saturating_sub` concern**: Using `saturating_sub` here means if `imem_sec_base < imem_virt_base`, the result silently becomes 0 instead of signaling an error. While this shouldn't happen with valid firmware, `checked_sub` + `ok_or(EINVAL)?` would be more defensive. The same concern applies to the NS len computation:
```rust
len: self.imem_load_size.saturating_sub(self.imem_sec_size),
```
Previously this used `checked_sub` which would return `None` and make `imem_ns_load_params` return `None`. Now with `saturating_sub`, if `imem_sec_size > imem_load_size` (corrupt firmware), the len would be 0 and an empty load would be attempted rather than skipping NS entirely. This behavioral change is worth verifying is intentional.

The `dst_start` calculation also uses `saturating_add`:
```rust
dst_start: self.imem_phys_base.saturating_add(imem_sec_start),
```
Same concern — overflow would produce a wrong value silently.

---
Generated by Claude Code Patch Reviewer