Add 24-hour soak test for ConcurrentPulseMap and ShardedPulseMap

[ddsha441981]

Summary

PulseMap needs an endurance test that runs continuously for 24+ hours to verify stability under sustained load. This catches issues that short benchmarks miss: slow memory leaks, priority score drift, epoch counter edge cases, and slab pool fragmentation.

What To Do

Create examples/soak_test.rs that:

Test Parameters

• Duration: Configurable via CLI arg (default 24 hours, minimum 1 hour for CI)
• Threads: 8 writer threads + 4 reader threads running continuously
• Map: ShardedPulseMap<u64, u64> with 4096 buckets/shard
• TTL: Enabled (set_ttl(10_000)) so entries expire and slots are reused continuously

What To Verify (print stats every 60 seconds)

• len() stays within expected bounds (never exceeds capacity)
• eviction_count() increases monotonically (never wraps or resets)
• No panic, no deadlock, no hang
• RSS memory (read from /proc/self/status on Linux) stays flat — no unbounded growth
• Data integrity: periodically insert known sentinel keys and verify they return correct values before TTL expiry

Output Format

[00:01:00] len=52431 cap=262144 load=20.0% evictions=148291 rss=31.2MB ops=12.4M
[00:02:00] len=52387 cap=262144 load=20.0% evictions=302841 rss=31.2MB ops=25.1M
...
[24:00:00] PASSED — 24h soak complete. Total ops: 1.08B, RSS drift: +0.0MB

Failure Conditions (test should exit with non-zero)

• RSS grows by more than 10% from initial measurement
• len() exceeds capacity()
• Any sentinel key returns wrong data
• Any thread panics

How To Run

# Full 24-hour soak
cargo run --release --example soak_test --features std

# Quick 1-hour CI smoke test
cargo run --release --example soak_test --features std -- --duration 3600

Acceptance Criteria

• examples/soak_test.rs compiles and runs
• Stats printed every 60 seconds
• Memory leak detection via RSS monitoring
• Data integrity checks via sentinel keys
• Configurable duration via CLI argument
• Runs successfully for at least 1 hour on contributor's machine