Claude review: gpu: nova-core: gsp: add sync and async command queue API to `Cmdq`

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

Patch Review

**Status: Looks good, minor observations**

This patch adds the type infrastructure for distinguishing sync vs async commands.

The `NoReply` marker type is simple and effective:
```rust
+pub(crate) struct NoReply;
```
Not implementing `MessageFromGsp` means `send_sync_command` cannot accidentally be called with an async command — this is enforced at compile time via the `M::Reply: MessageFromGsp` bound.

The `Reply` associated type on `CommandToGsp`:
```rust
+    /// Type of the reply expected from the GSP, or [`NoReply`] for async commands.
+    type Reply;
```
This is cleaner than a boolean `IS_ASYNC` constant since it carries the reply type information that `send_sync_command` needs.

The `send_sync_command` implementation:
```rust
+    pub(crate) fn send_sync_command<M>(&mut self, bar: &Bar0, command: M) -> Result<M::Reply>
+    where
+        M: CommandToGsp,
+        M::Reply: MessageFromGsp,
+        ...
+    {
+        self.send_command(bar, command)?;
+        loop {
+            match self.receive_msg::<M::Reply>(Delta::from_secs(10)) {
+                Ok(reply) => break Ok(reply),
+                Err(ERANGE) => continue,
+                Err(e) => break Err(e),
+            }
+        }
+    }
```

**Observation:** The `ERANGE` loop retries with a fresh 10-second timeout each iteration. If the GSP keeps sending non-matching messages (e.g. asynchronous notifications), this could loop for a very long time. Currently this is likely fine since the cover letter says "we expect GSP to be fast," but a comment noting this assumption or an overall retry limit would be defensive. This is a pre-existing pattern from `get_gsp_info()` which this patch consolidates — so it's not a regression.

The `send_async_command` properly constrains `Reply = NoReply`:
```rust
+    pub(crate) fn send_async_command<M>(&mut self, bar: &Bar0, command: M) -> Result
+    where
+        M: CommandToGsp<Reply = NoReply>,
```

Making `send_command` private (`fn` instead of `pub(crate) fn`) is correct — callers should now go through the sync/async variants.

The migration of `get_gsp_info` from a manual send+receive loop to a single `send_sync_command` call is a nice cleanup:
```rust
-    cmdq.send_command(bar, GetGspStaticInfo)?;
-    loop {
-        match cmdq.receive_msg::<GetGspStaticInfoReply>(Delta::from_secs(5)) {
-            ...
-        }
-    }
+    cmdq.send_sync_command(bar, GetGspStaticInfo)
```

**Note:** The old code used a 5-second timeout; the new `send_sync_command` uses 10 seconds. This is a behavior change (doubled timeout) though likely intentional.

The `SplitCommand` correctly propagates the `Reply` type:
```rust
+    type Reply = C::Reply;
```

All command types are properly annotated. This patch is solid.

---

---
Generated by Claude Code Patch Reviewer