fix: prevent SQLITE_BUSY by limiting to single connection

[mboyd1]

SetMaxOpenConns(1) serializes writes through one connection, eliminating SQLITE_BUSY errors under concurrent HTTP load. Also adds cache_size, mmap_size, and temp_store pragmas for better throughput.

What Changed

• Set db.SetMaxOpenConns(1) in the SQLite store to serialize all database access through a single connection
• Added cache_size=-64000 (64MB page cache), mmap_size=268435456 (256MB memory-mapped I/O), and temp_store=MEMORY pragmas

Why It Was Necessary

• Under concurrent POST traffic to /tx and /txs, multiple goroutines attempted simultaneous writes to SQLite
• SQLite only supports a single writer at a time — concurrent write attempts returned SQLITE_BUSY (5) even with the existing 5s busy_timeout, causing HTTP 500 responses: {"error":"failed to store status:
  failed to insert status: database is locked (5) (SQLITE_BUSY)"}
• The additional pragmas compensate for the single-connection bottleneck by reducing disk I/O per query

Testing Performed

• All existing go test ./... pass
• Deployed to production server receiving live transaction traffic
• SQLITE_BUSY errors eliminated after deployment

Impact / Risk

• Low risk — single-connection mode is SQLite's recommended configuration for server workloads with WAL mode
• Write throughput is serialized but not degraded in practice since SQLite was already single-writer; this just moves the queuing from the SQLite lock manager to Go's connection pool
• Read performance is unaffected — WAL mode allows concurrent reads from the same connection

Notifications

• @mboyd1

[github-actions]

👋 Thanks, @mboyd1!

This pull request comes from a fork. For security, our CI runs in a restricted mode.
A maintainer will triage this shortly and run any additional checks as needed.

• 🏷️ Labeled: fork-pr, requires-manual-review
• 👀 We'll review and follow up here if anything else is needed.

Thanks for contributing to bsv-blockchain/arcade! 🚀

[mrz1836]

LGTM