fix: eliminate full-table scans when parsing large Cursor state.vscdb…

[chomoe327]

Fixes #46

Problem

On a large Cursor state.vscdb, aiusage parse shows the cursor source
progress at 100% and then spins the CPU (9–14%) for 10+ minutes without
exiting; aiusage serve hangs the same way during its startup parse,
making the tool unusable.

Diagnostic data from the affected machine (2.75GB db, cursorDiskKV =
210,517 rows):

key prefix	rows	size
bubbleId:	90,260	1024 MB
agentKv:	103,131	1007 MB
checkpointId:	5,293	141 MB
composerData:	857	78 MB

lsof showed the process holding a read handle on the db; sample
showed the main thread busy in V8 (CPU-bound, not I/O wait or lock
contention); the db itself is healthy (all sqlite3 CLI queries return
instantly, no corruption, no WAL lock).

Root cause

The parser issues one WHERE key LIKE 'bubbleId:<composerId>:%' query
per composer. SQLite's LIKE is case-insensitive by default
(case_sensitive_like=OFF in better-sqlite3), so it cannot use the
key TEXT UNIQUE auto-index — EXPLAIN QUERY PLAN confirms
SCAN cursorDiskKV for every such query. With ~850 composers that means
850+ sequential full-table scans of a 2.75GB table.

Two aggravating factors:

• The existing watermark (CursorCursor) was applied in JS only after
  the full load, so incremental runs re-scanned the whole table too.
• The SQLite stage emitted no progress — just a single 1/1 event after
  the entire parse finished.

Fix

• Replace LIKE prefix matching with index-friendly range bounds
  (key >= 'bubbleId:<id>:' AND key < 'bubbleId:<id>;', likewise for
  composerData:). The query plan becomes
  SEARCH cursorDiskKV USING INDEX sqlite_autoindex_cursorDiskKV_1.
  Cursor writes keys with exact lowercase prefixes, so binary range
  comparison matches the same rows as the ASCII case-insensitive LIKE.
• Incremental runs with no new composers now never touch bubble rows —
  the watermark short-circuits before any bubble query.
• Skip databases whose schema has no cursorDiskKV table (e.g. residual
  dbs from old/uninstalled versions) instead of throwing.
• Report per-composer progress during the SQLite stage through the
  existing ProgressReporter.

No watermark format change, no new dependencies, and the db is still
opened read-only.

Testing

• New unit tests (real in-memory better-sqlite3 fixtures): missing-table
  degradation, unrelated key-prefix isolation (agentKv: etc. never
  leak into stats), per-composer progress callback, and no progress
  events on no-op incremental runs. Full suite: 53 files / 415 tests
  passing.
• Verified against the real 2.75GB state.vscdb (read-only):
  • Per-composer token sums diffed against an independent single-pass
    aggregation over all 90,260 bubbleId: rows — 0 mismatches.
  • Cursor token total after parsing: 114,900,780 — identical to
    the pre-fix value, no data loss.

Before / after (same machine, same db)

scenario	before	after
cursor source full parse (2.75GB db)	10+ min, never finished	~10s
aiusage parse (incremental re-run)	full re-scan, hung	~1s
aiusage serve startup parse	hung, dashboard never up	~3s