Document HashMap iteration-order invariant, improve SizeCache panic message

Review follow-up:

- map_compute_size_stmt uses .values() when key size is constant, while
  map_write_to_stmt always uses for (k, v). The cache-slot order between
  these must match. For HashMap (both std and hashbrown) it does — both
  walk the table in slot order — but this is not obvious from a cold read.
  Added a comment at the optimization site.

- next_size() previously panicked with a generic index-out-of-bounds
  message. Now reports cursor position vs slot count, with #[track_caller]
  so the panic location points at the caller. Helps manual Message
  implementers diagnose traversal-order mismatches.

- Dropped model: opus from the rust-code-reviewer agent definition.
  That model was emitting text-based pseudo-tool-call syntax the harness
  does not parse (tool_uses: 0 on every run), so all findings were
  confabulated from nonexistent file content. Inherits the main loop
  model now.

Author: iainmcgin

.claude/agents/rust-code-reviewer.md

@@ -2,7 +2,6 @@
 name: rust-code-reviewer
 description: Expert Rust code reviewer. Reviews Rust code for quality, safety, idioms, performance, maintainability, readability, and API ergonomics.
 tools: Read, Glob, Grep
-model: opus
 ---
 
 You are an expert Rust code reviewer with deep knowledge of:

buffa-codegen/src/impl_message.rs

@@ -2483,6 +2483,12 @@ fn map_compute_size_stmt(
     let val_const = map_element_size_is_constant(val_ty);
     // Iterate only the side(s) whose size varies: avoids unused-variable
     // and clippy::for_kv_map lints for bool/fixed* map key or value types.
+    //
+    // The (true, false) arm uses `.values()` here while `map_write_to_stmt`
+    // uses `for (k, v) in &map`. Cache slot order must match between the two
+    // passes. For HashMap (both std and hashbrown), `.values()` and `.iter()`
+    // walk the same table slots in the same order — identical sequence for an
+    // unmodified instance, which `&self` guarantees across both passes.
     Ok(match (key_const, val_const) {
         (true, true) => quote! {
             {

buffa/src/size_cache.rs

@@ -92,8 +92,16 @@ impl SizeCache {
     /// generated code this indicates a codegen bug; for manual `Message`
     /// implementations it indicates a traversal-order mismatch.
     #[inline]
+    #[track_caller]
     pub fn next_size(&mut self) -> u32 {
-        let size = self.sizes[self.cursor];
+        let size = *self.sizes.get(self.cursor).unwrap_or_else(|| {
+            panic!(
+                "SizeCache cursor overrun: write_to consumed {} slots but \
+                 compute_size produced {} (traversal-order mismatch)",
+                self.cursor + 1,
+                self.sizes.len()
+            )
+        });
         self.cursor += 1;
         size
     }