Benchmark Enhancements

[110CodingP]

This issue is a continuation of #24 .

Note: The recommendations below are AI-generated based on an evaluation of the benchmark suite in benches/create_wallet.rs. It may happen that these are non-issues.

1. Sample Size & Measurement Time Tuning for Large Syncs

• Context: large_sync generates ~15,000 transactions per setup iteration. Under Criterion's default 100 sample size, setup generates ~1,500,000 transactions across iterations, leading to high CPU setup latency before measurements begin.
• Proposal: Configure .sample_size(10..20) or custom .measurement_time(Duration::from_secs(10)) on the large_sync benchmark group to optimize runtime without losing statistical accuracy.

2. Spending Transactions & UTXO Graph Traversal

• Context: Current transactions generated by receive_output are flat funding outputs (input: vec![]).
• Proposal: Introduce a proportion of spending transactions that consume existing wallet UTXOs to create change outputs and payments. This will test outpoint indexing, spend-graph DAG traversal, and conflict tracking under redb.

3. Incremental / Sequential Persistence Benchmarks

• Context: The existing benchmarks measure a single bulk persist() of an entire sync changeset.
• Proposal: Add a benchmark simulating continuous block-by-block polling by performing multiple sequential persist() calls on the same store instance. This measures table growth, B-tree page splits, and append latency over time.

---

Action Items

• Add sample size tuning to large_sync benchmarks.
• Add chained/spending transactions to the sync simulation helper.
• Implement an incremental multi-persist benchmark group.