Stop StateHistory panicking when the trace buffer has zero capacity

[deepspace28]

spacewasm-trace --limit 0 crashes:

thread 'main' panicked at crates/spacewasm_util/src/trace.rs:38:27:
index out of bounds: the len is 0 but the index is 0

--limit parses straight into StateHistory::new, and 0 is accepted. On the first recorded instruction record takes the else branch and indexes an empty Vec. Past that line, (self.index + 1) % self.capacity would divide by zero.

record now returns early when capacity is zero, so the buffer holds nothing and the tool prints an empty trace instead of aborting.

Before, on a module with one exported function:

$ spacewasm-trace add.wasm --limit 0
thread 'main' panicked at crates/spacewasm_util/src/trace.rs:38:27

After:

=== Execution Trace (last 0 instructions) ===
===============================================

Result: Completed successfully

Also adds tests/state_history.rs. spacewasm_util had no tests at all, so these cover the ring buffer rather than only the zero case: ordering below capacity, at capacity, across several wraps, capacity one, empty iteration, and dump output including metadata. With the fix reverted, zero_capacity_records_nothing fails and the other eight pass.

cargo fmt --all -- --check and cargo clippy -p spacewasm_util --all-targets --all-features -- -D warnings are both clean.

Generative AI disclosure

Per AI_POLICY.md. This change is confined to crates/*; no src/* code was touched.

• Type of assistance: bug diagnosis, the one-line guard, and the tests
• Scope: crates/spacewasm_util/src/trace.rs, crates/spacewasm_util/tests/state_history.rs
• Tool: Claude (Claude Code)
• Level of modification: reviewed and edited before submitting. Every test was run locally, and the panic was reproduced through the CLI both before and after the fix.

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide, as well as our policy regarding AI usage, and we look forward to reviewing your pull request shortly