Claude review: rust: clist: Add support to interface with C linked lists

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

Patch Review

**File Organization Issue:**
```rust
// Location: rust/kernel/clist.rs
```
**Problem:** Should be moved to `rust/kernel/ffi/clist.rs` to make it obvious this is FFI infrastructure (raised by Danilo Krummrich).

**Recommendation:** Move to `rust/kernel/ffi/` directory structure.

**Documentation Clarity:**
```rust
+//! A C doubly circular intrusive linked list interface for rust code.
```
**Problem:** Doesn't explicitly warn against using this in pure Rust code.

**Recommendation:** Add explicit FFI-only warning:
```rust
//! **FFI Use Only**: This module provides interfaces to C linked lists for FFI
//! scenarios only. Pure Rust code should use standard Rust collection types.
```

**Critical Logic Error in `is_linked()`:**
```rust
+    /// Check if this node is linked in a list (not isolated).
+    #[inline]
+    pub fn is_linked(&self) -> bool {
+        let raw = self.as_raw();
+        // SAFETY: self.as_raw() is valid per type invariants.
+        unsafe { (*raw).next != raw && (*raw).prev != raw }
+    }
```

**Problem:** This logic is incorrect for empty list heads (sentinels). An initialized empty list has `next == prev == &self`, which this would report as "not linked". The function conflates:
1. A sentinel head that is initialized (empty or not)
2. A node that is part of a list

For an empty list: `head->next == head->prev == head` should still be considered valid.

**Recommendation:** Rename and clarify semantics:
```rust
/// Returns true if this node is linked to other nodes (not a singleton).
/// An initialized empty list head returns false.
pub fn has_nodes(&self) -> bool { ... }
```

**Soundness Concern with Sync:**
```rust
+// SAFETY: [`CListHead`] can be shared among threads as it is not modified
+// by non-Rust code per safety requirements of [`CListHead::from_raw`].
+unsafe impl Sync for CListHead {}
```

**Problem:** The `Sync` implementation relies on "not modified by non-Rust code" guarantee. In kernel FFI contexts where C code may modify lists concurrently, this could be unsound.

**Recommendation:** Document this limitation clearly or add synchronization primitives.

**Offset Calculation (Correct):**
```rust
+        Some(unsafe { &*head.as_raw().byte_sub(OFFSET).cast::<T>() })
```
This is correct usage of `offset_of!` and pointer arithmetic with adequate safety justification.

**Verdict:** Needs fixes for organization, documentation, and the `is_linked()` logic error before merge.

---

---
Generated by Claude Code Patch Reviewer