Claude review: gpu: nova-core: gsp: support large RPCs via continuation record

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

Patch Review

This is the core patch. Three new types are introduced:

**`ContinuationRecord<'a>`**: A simple command that writes its payload as-is, using `type Command = ()` (zero-size header). This correctly means the entire element payload is variable data.

**`SplitState<C>`**: Determines whether splitting is needed and manages the staging buffer. Key constants:

```rust
const MAX_CMD_SIZE: usize = GSP_MSG_QUEUE_ELEMENT_SIZE_MAX - size_of::<GspMsgElement>();
const MAX_FIRST_PAYLOAD_SIZE: usize = Self::MAX_CMD_SIZE - size_of::<C::Command>();
```

The split decision in `new()` is correct — only when `command_size(inner) > MAX_CMD_SIZE` does staging occur. The staging buffer is populated eagerly by calling `inner.init_variable_payload()` once, which avoids calling the user's init function multiple times.

**`SplitCommand<'a, C>`**: An enum wrapping either the original command (`Single`) or the truncated first-chunk version (`Split`). The `CommandToGsp` impl for `Split` truncates `variable_payload_len()` to `MAX_FIRST_PAYLOAD_SIZE` and copies from the staging buffer.

The updated `send_command` flow is clean:

```rust
let mut state = SplitState::new(&command)?;
self.send_single_command(bar, state.command(command))?;
while let Some(continuation) = state.next_continuation_record() {
    self.send_single_command::<ContinuationRecord<'_>>(bar, continuation)?;
}
```

**One observation**: `command_size` is changed from `fn` to `pub(crate) fn` to allow access from `commands.rs`. This is a minor visibility escalation that's fine for a crate-internal function.

**Observation on `next_continuation_record` continuation chunk sizing**: Each continuation record gets at most `MAX_CMD_SIZE` bytes of payload. Since `ContinuationRecord` has `type Command = ()` (zero-size), the total element size is `size_of::<GspMsgElement>() + chunk_size`, which maxes out at exactly `GSP_MSG_QUEUE_ELEMENT_SIZE_MAX`. This correctly stays within the per-element limit and won't trigger the `EMSGSIZE` check added in patch 4.

**Minor style nit**: The `_phantom: PhantomData` field in `SplitState` exists because the struct needs to carry the `C` type parameter for the associated constants (`MAX_CMD_SIZE`, `MAX_FIRST_PAYLOAD_SIZE`). This is a standard Rust pattern and is fine.

**Question for the author**: The cover letter mentions "continuation record for receive is not necessary to support at the moment because those replies do not need to be read and are currently drained by retrying `receive_msg` on ERANGE." Is there a concern that GSP could *respond* with continuation records to these large RPCs? If so, silently draining them seems fragile if future RPCs need to read large responses. A `dev_warn!` or tracking note might be useful there, though this is outside the scope of this series.

---
Generated by Claude Code Patch Reviewer