Summary

Two independent fixes to the initial scan/index path. Measured on a ~16k-file repo with a cold codedb index:

−77% memory, ~6.5× faster — no functional change.

1. Memory — per-file scratch arena (src/watcher.zig)

Each parse worker held one long-lived page_allocator arena for its entire chunk. parseContentForIndexing throws off large transient parse state (AST/token buffers) that isn't part of the returned content/outline; an arena never reclaims freed memory, so each worker's arena ballooned to the high-water-mark of every file's transients across its whole chunk (~3.5 GB total).

Now each file is parsed in a per-file scratch arena that resets between files; only keep-data (content dupe + Explorer.cloneOutline, made pub) is copied into the persistent results arena. The threading model is unchanged — parse parallel, commit serial on the main thread — so the per-worker copy is race-free.

2. Speed — symbol-index O(n²) (src/explore.zig)

commit called removeSymbolIndexFor per file, which scans the entire global symbol index to evict the path's old entries. On a cold scan every file is brand-new (nothing to evict), so the whole pass was O(files × total_symbols) — billions of comparisons. Skip the scan when the path has no prior entry (had_prior=false).

Commit phase: 23,713 ms → 1,517 ms (14×).

Phase breakdown (after)

walk:                70 ms
parse (parallel x8): 495 ms
commit (serial):  1,517 ms   (was 23,713 ms)
trigram-build:      628 ms
snapshot:           261 ms

The parse was already fast (0.5s), so the win came from the commit, not from adding parallel workers.

Verification

• zig build test → 670/670 pass
• Rebuilt the index and confirmed search (50 hits) and symbol lookup (find) return correct results.

Also bumps build.zig.zon to 0.2.5824.