perf(scanner): batch inserts + bulk snapshot eviction (~33x on 1 GB)

[Dig1taly]

Summary

Replaces the per-message INSERT/DELETE loop in `scan_file()` with batched `executemany()` and a single temp-table-driven snapshot eviction. Observable behavior is unchanged; throughput is dramatically higher on heavy data sets.

Measured speedup

On a real `~/.claude/projects` of 1.0 GB / 566 files / ~200k messages:

	Time	Notes
Before (main `5375650`)	4773 s (~80 min)	Full first scan from empty DB
After (this PR)	145 s (~2.4 min)	Same workload, same machine
Speedup	~33×

Incremental scans (the common case once the DB is built) stay fast either way - the per-file mtime/offset short-circuit short-circuits before the new code path even runs.

What changed

All inside `token_dashboard/scanner.py`. Public API of `scan_file` and `scan_dir` is unchanged.

• `_parse_file()` - pure-Python parser that returns lists of dicts and an `end_offset`. No DB access. Splits the parsing concern from the writing concern.
• `_dedupe_inflight_snapshots()` - collapses streaming snapshots within the in-memory batch before any DB work. Same semantics as `_evict_prior_snapshots()` (keep only the last uuid per `(session_id, message_id)`), just done in Python over the new batch.
• `_evict_prior_snapshots_bulk()` - replaces N inline `SELECT + DELETE` round-trips with one temp-table JOIN against `messages`, followed by chunked `DELETE ... IN (...)` against both `messages` and `tool_calls`. Chunks stay under SQLite's default `SQLITE_MAX_VARIABLE_NUMBER` (999).
• `scan_file()` - now parses to memory, dedupes the batch, bulk-evicts prior snapshots, then writes messages and tools via `executemany`. Partial-line / EOF / decode-error handling preserved verbatim.

Constraints respected

• Stdlib only. No new dependencies, no `pip install`.
• Public function signatures and return shape unchanged.
• Streaming-snapshot semantics preserved (`test_scanner_dedup.py` is the authoritative spec; passes).
• Partial-line handling preserved (`test_scanner_rescan.py` exercises the appended-lines path; passes).
• All inserts still use parameterized SQL.

Why it's so much faster

Two compounding wins on heavy data sets:

1. Per-message INSERT round-trips eliminated. Python ↔ SQLite has measurable per-call overhead. With ~200k messages and ~115k tool rows, switching to `executemany` removes hundreds of thousands of context switches.
2. Eviction round-trips eliminated. The old code ran a `SELECT` then a per-snapshot `DELETE` for every assistant message that carried a `message.id`. On long sessions with many streaming snapshots, that was the dominant cost. One temp-table JOIN at end-of-file does the same work in O(file) instead of O(messages).

Tests

```
$ python -m unittest discover tests
Ran 71 tests in 17.170s
OK
```

Including the eviction tests in `test_scanner_dedup.py` which directly exercise the new `_evict_prior_snapshots_bulk` path through `scan_file` and verify that earlier snapshots are dropped from both `messages` and `tool_calls` while the final tally survives.

Not in this PR (deliberately)

• No process-pool parallelism. `ProcessPoolExecutor` on Windows uses `spawn` with pickle IPC overhead per task, which would partially erode the win on the dataset size where it matters most. Worth revisiting separately with a benchmark.
• No `orjson` / `msgspec`. Stdlib-only rule.
• No schema changes. Same DB file is readable by older `token-dashboard` versions after this code runs against it.

Happy to split into smaller commits, rename anything, or rework if you'd like a different shape.

[muckybuzzwoo]

Integrated this into a fork at https://github.com/muckybuzzwoo/token-dashboard (commit 870c8db) with one adaptation: scan_file's return value now also carries the days and sessions sets that the fork's materialised summary tables need for incremental rebuild — without those, summaries would silently grow stale after every scan.

Real-world measurement on the fork's owner's DB: ~600 files / 60k+ messages full rescan completes in ~7.5 seconds. Thanks for the speedup!