perf(agent): cheaper novelty scoring; complete the consolidation benchmark

consolidation_efficiency never finished: stopped after 19 minutes on one
core while building its 100K case. Not the consolidation cycle (linear:
17 us at 100 records, 2.16 ms at 10K) but the setup — every add_memory
scores the new record's novelty against the whole working tier, the
benchmark lets that tier reach 50K, and each comparison recomputed both
norms: ~5e9 comparisons of three passes each.

ImportanceScorer::score_surprise now computes the new record's norm
once, takes each comparison in one fused, 8-lane pass (dot product and
the other norm together), and splits a working tier of 4096+ records
across threads with the `parallel` feature. Same results: tested against
the old cosine formula, including shorter, empty and zero vectors and
the parallel path. The work stays quadratic in the working-tier size by
design; with regular consolidation the tier stays near
working_capacity (100) and inserts are cheap.

The complete run takes 8 min 10 s on tank and fills in the 100K cycle
row (46.66 ms) and the memory-reduction table, which had never been
published. The binary no longer prints a record-count ratio as a
"BM25 Speedup" (never measured; Part 1 measures search latency) or
claims sub-linear cycle scaling (its own numbers grow slightly faster
than linearly).

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>

crates/clawhdf5-bench/src/bin/consolidation_efficiency.rs

@@ -396,7 +396,7 @@ fn run_memory_reduction_benchmark() {
     println!();
     println!(
         "{:>8}  {:>10}  {:>10}  {:>10}  {:>12}",
-        "Initial", "Remaining", "Eviction%", "Signal OK?", "BM25 Speedup"
+        "Initial", "Remaining", "Eviction%", "Signal OK?", "Records ÷"
     );
     println!("{}", "-".repeat(58));
 
@@ -440,7 +440,8 @@ fn run_memory_reduction_benchmark() {
         // Check all signal records survived
         let signal_survived = signal_ids.iter().all(|&id| engine.get_by_id(id).is_some());
 
-        // Rough speedup: BM25 scales roughly linearly with record count
+        // How many times fewer records there are. Not a measured speedup —
+        // Part 1 measures search latency before and after.
         let speedup = before_count as f64 / after_count.max(1) as f64;
 
         println!(
@@ -480,7 +481,7 @@ fn main() {
     println!("  3. Reducing search latency proportional to record reduction");
     println!();
     println!(
-        "Cycle time scales sub-linearly: 100 records ~microseconds, 100K records ~tens of ms."
+        "Cycle time grows a little faster than linearly: 100 records ~microseconds, 100K records ~tens of ms."
     );
     println!("Signal records with Correction source + high access_count survive eviction.");
 }