#495 perf(config): read the deprioritize config once per ranking pass

codegraph_explore answers are a median 4% faster on a Go project (gin), 7% on a NestJS project and 0.6% on a large TypeScript project (n8n) because the codegraph.json check runs once per ranking pass instead of once per result path. The gain is small: on every row it sits inside the measurement's own run-to-run variation, so I can show the direction but not a clear speedup.

Warm codegraph_explore call, median of 5 rounds	Before	After	Benefit	Run-to-run spread (A/A)
gin (Go)	19.5 ms	18.7 ms	4.0% faster	9.5%
gin with a codegraph.json	19.2 ms	18.3 ms	4.6% faster	12.6%
nest (TypeScript)	39.8 ms	37.0 ms	7.0% faster	6.1%
n8n (TypeScript, large)	212.9 ms	211.5 ms	0.6% faster	7.4%
All timed calls summed, gin / nest / n8n	2,626 / 3,571 / 27,216 ms	2,515 / 3,420 / 27,342 ms	4.2% faster / 4.2% faster / 0.5% slower	9.9 / 4.6 / 7.4%

Peak server memory, cold start to the first answer and the answers themselves are unchanged (every response hash identical in every round; memory and cold-start differences are inside their spreads). Method: 5 rounds, three arms per round (before, after, before again as the noise floor), builds f045e5f7 and the same plus this change, declared before the runs. Under the rule I declared there ("land only when a row is clear") this change was not landed; I am landing it on the direction of the result, a consistent 4–7% on three of four rows, no regression anywhere, and a change that is a few lines.

What changes

After #491 the matcher for deprioritize patterns still read codegraph.json (an mtime check) for every result path it was asked about. The matcher is now a provider: getDeprioritizedPathMatcher() reads the config once and returns a predicate that callers reuse for every path in a ranking pass (searchNodes scoring and the two ranking loops in ContextBuilder). No patterns gives no predicate at all. Editing, adding or deleting codegraph.json is still picked up on the next query.

Checks

• Full vitest suite on this head: 702 files, 8,954 passed, 39 skipped, 0 failed (head c0efc6d7); no Native stack trace or Worker exited unexpectedly in the raw output.
• New test in __tests__/deprioritize-config.test.ts: a ranking pass over 17 paths reads the config once; it fails on the old source (17 reads).
• README: checked "About this fork"; no row mentions this path. CHANGELOG entry added under Fixes.
• QueryBuilder is exported, so setDeprioritizedPathMatcher keeps taking a plain path predicate; the provider form is the separate setDeprioritizedPathProvider (covered by a test).

Not covered: Windows and macOS timing; projects with large deprioritize lists.