feat(fastsync): /fastsync/anchors feed + concurrent (SQLite/WAL) bundle store (#115)

[LiranCohen]

Summary

Completes Option B of the fast-sync overlay (epic #111): the verifiable anchor-bundle HTTP feed, plus the concurrency fix that unblocks it.

The concurrency fix

serve (reader) and start (writer) are separate processes. #113's bundle store was bbolt — a single-process exclusive lock — so they couldn't both open it. This converts the bundle store to SQLite/WAL (the same property anchors.db already relies on for concurrent start+serve), keeping the exact Put/Get/Range API so #113's indexer wiring and tests are unchanged. Still fail-closed / no reorg rollback (a stale bundle fails the client's merkle check; re-index overwrites).

The feed

• internal/fastsync/service.go — Service, the transport-agnostic serving core (shared with Option C fast-sync C: native P2P messages via a vendored btcd wire (getanchors/anchors, getcas/cas) #122). AnchorBundles(from,to) reads the store, clamped to a max height span + max bundle count.
• GET /fastsync/anchors?from=&to= → {"anchors":[{height,txIndex,rawTx hex,branch hex[]}]}, CORS-open. The client reconstructs each bundle and verifies its merkle proof against its own PoW headers — the source can only omit, never forge.
• --serve-fast-sync now both (a) makes start capture bundles and (b) makes serve expose /fastsync/cas + /fastsync/anchors.

To populate bundles in production: run start --serve-fast-sync (captures going forward; a re-index backfills history).

Tests

• Service range/order/bounds.
• Two concurrent Store handles (modeling the start writer + serve reader) read+write the same file — a bbolt store would fail the 2nd Open.
• The /fastsync/anchors endpoint serialized a bundle that a client reconstructs and VERIFIES after the JSON round-trip (+ CORS, bad-range 400, route-absent 404).

go test -race ./... green (28 packages).

Post-Deploy Monitoring & Validation

• What to watch: with start --serve-fast-sync, bundles.db grows as anchors are indexed; serve --serve-fast-sync answers GET /fastsync/anchors?from=&to= with bundles a client can verify. The two processes share bundles.db via WAL.
• Failure signal / trigger: empty /fastsync/anchors despite indexed anchors → start wasn't run with --serve-fast-sync (no capture) or history needs a re-index backfill.
• Window/owner: when a node opts into serving fast-sync.

Part of #111. Closes #115.

🤖 Generated with Claude Code