Claude review: rust: add ordered workqueue wrapper

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

Patch Review

**Concerns about the helper and API design.**

The C helper:

```c
+rust_helper_alloc_ordered_workqueue(const char *name, unsigned int flags)
+{
+	return alloc_ordered_workqueue("%s", flags, name);
+}
```

This correctly avoids format string issues by using `"%s"` as the format. Good.

The `OrderedQueue` type:

```rust
+pub struct OrderedQueue(NonNull<bindings::workqueue_struct>);
```

1. **`enqueue` uses `Queue::from_raw`**: The `enqueue` method does:

```rust
+    pub fn enqueue<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
+    where
+        W: RawWorkItem<ID> + Send + 'static,
+    {
+        // SAFETY: `self.0` is valid while `self` is alive.
+        unsafe { Queue::from_raw(self.0.as_ptr()) }.enqueue(w)
+    }
```

This creates a temporary `Queue` reference from the raw pointer just to call `enqueue`. This works but means `OrderedQueue` doesn't expose other `Queue` methods (like `try_spawn`). This is fine for the current use case but you might consider providing an `as_queue(&self) -> &Queue` method or implementing `Deref<Target=Queue>` for more general use. That said, keeping the API minimal is also reasonable for now.

2. **Drop safety comment**: The drop impl says:

```rust
+        // - `OrderedQueue` does not expose delayed scheduling API.
```

This safety comment seems tangential — the key invariant for `destroy_workqueue` is that the workqueue was allocated by `alloc_ordered_workqueue` and is being destroyed exactly once, which is guaranteed by `NonNull` ownership semantics.

3. **No `flush_workqueue` method**: Before destruction, `destroy_workqueue` in C already drains pending work. This is fine, but callers using `disable_work_sync` (patch 2) before dropping individual work items should be aware of the ordering — which patch 4 handles correctly.

---

---
Generated by Claude Code Patch Reviewer