fix(explore): wire .codedbrc max_cached into ContentCache capacity

[justrach]

Summary

• PR perf: CLOCK eviction cache for file contents #208 wired up the CLOCK content cache but hardcoded its capacity to 16384, leaving .codedbrc's max_cached parsed-and-forgotten.
• This PR threads cfg.max_cached through Explorer.init (and the MCP ProjectCache) so the knob actually controls cache size.
• Default bumped 1000 → 16384 so users without a .codedbrc see no behavior change vs. the (accidentally) shipped 16384.
• The issue-102 tests in src/tests.zig previously documented the deadness in comments; they're rewritten to assert the wiring end-to-end — they would have caught the original bug.

Files

• src/explore.zig — new pub const DEFAULT_CONTENT_CACHE_CAPACITY = 16384; Explorer.init now takes a capacity param; dead content_cache_limit field removed.
• src/hot_cache.zig — std.debug.assert(capacity >= 1) guard (capacity 0 used to silently panic on h % 0).
• src/config.zig — Config.max_cached default 1000 → 16384.
• src/main.zig — pass cfg.max_cached to Explorer.init and through to mcp.run.
• src/mcp.zig — ProjectCache carries the capacity; mcp.run and BenchContext.init signatures updated to thread it through.
• src/wasm.zig, src/bench.zig, src/benchmark.zig — pass DEFAULT_CONTENT_CACHE_CAPACITY at boundaries with no config in scope.
• src/tests.zig, src/adversarial_tests.zig — bulk-updated ~260 call sites; rewrote issue-102 tests to assert real wiring.

Test plan

• zig build test → exit 0 (all 536 tests pass on 4433aec)
• issue-102: Explorer.init capacity flows to ContentCache — constructs with capacity 8, asserts explorer.contents.capacity == 8
• issue-101+102: .codedbrc max_cached threads through to ContentCache capacity — parses max_cached = 32, asserts explorer.contents.capacity == 32
• Manual: drop a real .codedbrc with max_cached = 64 in a project, run codedb, confirm cache stats show capacity 64

Notes

• Targeting release/v0.2.5814 per the standing rule (collect fixes on release branch, never merge straight to main).
• Version bump (build.zig.zon + src/release_info.zig) intentionally not included — that belongs in the release commit when you're ready to cut v0.2.5814.
• Issue feat: config file max_cached #102 is already closed, so no Closes #102 footer.

🤖 Generated with Claude Code

[github-actions]

Benchmark Regression Report

Thresholds: 10.00% and 50,000 ns absolute delta

NOISE means the percentage threshold was exceeded, but the absolute delta was too small to fail CI.

Tool	Base (ns)	Head (ns)	Delta	Abs Delta (ns)	Status
codedb_bundle	468401	462518	-1.26%	-5883	OK
codedb_changes	53865	52837	-1.91%	-1028	OK
codedb_deps	9267	10845	+17.03%	+1578	NOISE
codedb_edit	7573	8048	+6.27%	+475	OK
codedb_find	64229	60338	-6.06%	-3891	OK
codedb_hot	95644	97432	+1.87%	+1788	OK
codedb_outline	281047	290283	+3.29%	+9236	OK
codedb_read	88329	94028	+6.45%	+5699	OK
codedb_search	140637	144671	+2.87%	+4034	OK
codedb_snapshot	286461	281411	-1.76%	-5050	OK
codedb_status	204264	206756	+1.22%	+2492	OK
codedb_symbol	61551	57985	-5.79%	-3566	OK
codedb_tree	65482	66434	+1.45%	+952	OK
codedb_word	66667	65843	-1.24%	-824	OK

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4433aecc53

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid building trigram indexes from a capped cache

When a user sets .codedbrc max_cached below the repo's file count, this line now bounds explorer.contents, but the cold non-search path still builds/persists trigrams only from that cache (main.zig:351-361) and Explorer.rebuildTrigrams also iterates only self.contents. That means the persisted/rebuilt trigram index can cover only the cached subset rather than every scanned outline, degrading later searches to slow skip/full scans and potentially omitting matches once earlier cached candidates fill max_results; build trigrams from disk or avoid the cache-only path when contents.count() != outlines.count().

Useful? React with 👍 / 👎.