perf(sp): eliminate per-tx DB iterator reads in tweaks.subscribe

[sethforprivacy]

Problem

Cake Wallet's on-device ("hardcore") Silent Payments sync is dominated by server-side per-candidate-transaction work in blockchain.tweaks.subscribe. For every tweak row streamed, the hot loop:

1. resolved the spend-cache height with a fresh RocksDB iterator scan per transaction (get_tweak_cached_height), while the main range scan runs with fill_cache(false) so these random reads never warm the block cache. A full-history scan streams ~4.03M candidate txs (~115.6M in historical mode); at 1–3 ms per cold random SST read this alone accounts for hours of scan time;
2. rebuilt and split the full script_pubkey.to_asm() string per vout just to recover the taproot key;
3. cloned tweak.vout_data per tx even when the spend cache was current.

Live measurements against electrs.cakewallet.com (cake-update-v1 @ cf9e03b): ~3–4 ms marginal cost per candidate tx cold vs ~0.2 ms warm (~20×); 0.44 s/block over a 300-block cold dense window, which projects to a 5–17 h serial full-history sync.

Fix

• Resolve the spend-cache state once per block via a memoized HashMap entry instead of once per transaction (~60× fewer reads on dense blocks).
• Replace the prefix iter_scan(...).next() in get_tweak_cached_height with a direct point get() — same fixed-length 5-byte key the write path (store_tweak_cache_height → put_sync) uses, so lookups are exact-match equivalent.
• Extract P2TR x-only keys straight from the script bytes (OP_1 <32 bytes> = 0x51 0x20 …), falling back to the previous asm-split path for anything non-P2TR.
• Iterate vout_data by reference; clone only on the stale-spend-cache path.

The row_height < last_blockchain_height - 5 guard is rewritten as row_height + 5 < last_blockchain_height — equivalent for all real tips, but no longer underflows u32 on very short (regtest) chains.

Second commit: streaming + last per-tx clone

An independent optimization pass added commit 2:

• Stream rows straight off the snapshot-consistent RocksDB iterator instead of collect()ing the entire requested range into a Vec before streaming — a dense historical-mode request otherwise holds hundreds of thousands of fully-deserialized rows in memory per connection and delays the first streamed block until the whole range has been read. The query handle is Arc-cloned so the iterator doesn't borrow self.
• Drop the remaining per-tx deep clone: get_tweak_data() cloned every vout script and spend record once per transaction row; the tweak data is now borrowed in place.

Wire compatibility

Output is byte-for-byte unchanged, chain-validated twice on regtest:

• Commit 1 vs the unpatched parent (aae16bf): identical normalized tweaks.subscribe payloads for all SP transactions, including a genuine BIP-352 payment (built with rust-silentpayments send math) that both the production sp_scanner path and the session scanner found identically.
• Commit 2 vs commit 1 (independent run, 2026-08-15): fresh regtest chain, index settled across restarts, both binaries serving the same DB → byte-identical payloads in both non-historical and historical modes.

Notes

• Builds clean with cargo build --release --features silent-payments. Reminder: the tweaks RPC only exists when the silent-payments feature is enabled — worth pinning in the deployment CI/Dockerfile.
• sp-scan-fast-path-v1 is the commit-1 change rebased onto cake-update-v1 (base cf9e03b, the binary currently serving production) for a drop-in redeploy of the live box if we want the win before the v2 index cutover; commit 2 can be cherry-picked there too if needed.
• Follow-up candidate (not in this PR): raise the count cap (1000) so clients can amortize the ~0.3 s fixed per-request overhead over larger ranges.

🤖 Generated with Claude Code

[sethforprivacy]

CI triage:

• test-liquid (fail → fixed in 381c927): p2tr_pubkey_hex took &bitcoin::Script, but liquid builds use elements::Script for script_pubkey. Now takes raw script bytes — identical logic for both types; cargo check --features liquid and cargo build --release --features silent-payments both verified locally. Cherry-picked to sp-scan-fast-path-v1 as well.
• nix (fail, pre-existing): the same job fails identically on cake-update-v2 itself (every run since 2026-02-25, bech32 ^0.9 version-selection error during dep vendoring) — unrelated to this PR.

🤖 Generated with Claude Code

[sethforprivacy]

The pre-existing nix failure is root-caused and fixed in #4 (Cargo.lock was internally inconsistent since the 9dffb84 merge — the nix job's strict offline vendoring was the only one that noticed). Once #4 merges, rebasing this branch on cake-update-v2 will turn the nix check green here too.

🤖 Generated with Claude Code