Fix silent-payment catch-up pegging the CPU (both threads)

A wallet a few thousand blocks behind gets the whole scan window from the
indexer at once (~1M tweaks over ~3900 mainnet blocks). The catch-up loop
chunked by 100 BLOCKS, but the cost is one EC point-multiply per TWEAK and
mainnet blocks are wildly uneven (up to 2565 tweaks each) — so a 100-block
chunk could be ~25k tweaks, seconds of work that blew the worker's 30s
timeout. On timeout the caller ran the SAME chunk inline on the main thread
while the orphaned worker kept grinding it, pegging both threads and
freezing the visible tab for the whole ~20min catch-up.

Two fixes:
- Chunk by tweak count (budget 2000, always ≥1 block) instead of block
  count, so every worker call stays sub-second regardless of block density.
  Verified against live mainnet data: max chunk drops from ~25k tweaks to
  ~2.8k (~850ms, <3% of the timeout).
- On a worker-call timeout, TERMINATE the worker instead of leaving it
  grinding the orphaned request behind the caller's inline fallback — that
  double-grind was the both-threads-pegged symptom. _ensureSpWorker respawns
  a fresh worker on the next call.

Diagnosed via CDP CPU profiling of the live tab (95% self-time in
_spHitBlocks -> _spCandidate -> secp256k1 wNAF/precompute).

Co-Authored-By: Claude Opus 4.8 <[email protected]>

0 files changed, 0 insertions, 0 deletions