fix(graph): survive un-indexable files, surface unresolved references, and stop storing references the resolver already turned into edges

[Yashasvi2229]

What

Five changes to the code graph, in the order they were built:

1. A file the corpus policy will not read is skipped, not fatal. A single
   oversized file used to abort the entire build, and the loop breaks so
   remaining files were never attempted. It is now recorded with zero
   nodes/edges and a per-path warning, and the walk continues. Corpus-wide
   ceilings still fail the build, because there is no sensible partial answer to
   those.
2. A config input outside the project root is declined, not fatal. For a
   source file, out-of-root was already a soft miss; for a tsconfig, the
   identical check threw and killed the build. configFileExists now returns
   false and readConfigFile returns undefined, with the declined
   specifier reported. The containment guard is unchanged — this only changes
   what happens when it declines.
3. A repository can add its own corpus ignore globs, additive to the built-in
   defaults, which stay non-overridable.
4. mex graph query who-calls falls back to recorded unresolved references
   when a name has call sites but no indexed declaration, emitted as a distinct
   record type, budgeted and capped.
5. References the resolver bound are no longer stored. They became edges;
   keeping them stored a second copy.

Plus: evaluate/RESULTS.md is now linked from the READMEs.

Why

Closes #115. References #140

#115 raised three items. Two were already fixed in 0.7.2 (graph scope
stopword filtering) and by the benchmark rework (the README's grep comparison
claim). The third — who-calls returning TARGET_NOT_FOUND with no recovery
path, while the call sites sat in an internal table no command exposed — is
fixed here. The reporter's own blind eval is the argument for it: on
call-site enumeration mex answered 23/23 where a regex answered 15/23, and
reaching that answer required hand-written SQL against internal schema.

The two hard aborts were found while measuring seven real repositories for
this work. Two of them could not be indexed at all, each because of one
file: a 34.4 MB generated source in a 3,259-file TypeScript monorepo, and a
tsconfig extending a package hoisted to a parent node_modules in a
517-file repository. Both are ordinary — hoisting is normal in any pnpm/yarn
workspace, and generated blobs are normal anywhere.

Two further defects surfaced while fixing those:

• The per-file limit name was selected by comparing byte values. The source and
  config per-file ceilings are numerically identical, so every oversized
  source file mex has ever rejected was reported as a config-limit breach.
• Freshness inspection in status.ts had the same break-on-limit shape as
  indexing. Left alone, status and indexing would have disagreed about the
  corpus permanently, and a repository with one oversized file could never read
  fresh.

The storage change is the cheap, safe half of the #140 follow-up. Measured
across five repositories, unresolved_refs and its indexes were 32–42% of
every store, and rows with status = 'resolved' were 27–61% of the table with
100% of them already present as an edge on every store checked. edges is
a superset, so nothing is recoverable from those rows that is not already
there.

Type of change

• Bug fix
• New feature
• Refactor
• Docs
• CI/Tooling

How to test

The two builds that used to be impossible

1. Point mex graph at a repository containing a source file above
   maxSourceFileBytes. Before: the whole build fails with
   GRAPH_CORPUS_LIMIT_EXCEEDED. After: it completes, and the file is reported
   as skipped with its size and the limit.
2. Point mex graph at a repository whose tsconfig.json extends a package
   resolved outside the project root. Before: the whole build fails with
   GRAPH_SOURCE_PATH_ESCAPE and filePath: ".". After: it completes and the
   declined config input is reported by its dependency specifier.

The fallback

3. mex graph query who-calls <name> for a name with call sites but no indexed
   declaration. Before: {"type":"error","code":"TARGET_NOT_FOUND"}. After:
   labelled unresolved records with file, line and column, under budget.

No graph content changed

4. Build the same repository on main and on this branch and compare. Node and
   edge counts, per-kind breakdown, and a content hash over
   (source, target, kind, line, col) are identical. Only the store shrinks.

Storage

5. SELECT name, SUM(pgsize) FROM dbstat GROUP BY name before and after.

Checklist

• Tests pass (npm test) — see note below
• No breaking changes (or documented below)
• Tested locally with a real project

Notes:

• Verified on a mid-size repository: node and edge content hashes identical
  across main and this branch; whole store −16.7%; unresolved_refs plus its
  indexes −39.9%.
• npm run eval could not be used as a gate. It fails identically on clean
  main with a RangeError reading lsh_buckets in
  evaluate/graph/lib/integrity.mjs — the v3 band hashes exceed
  Number.MAX_SAFE_INTEGER and node:sqlite refuses to return them as
  numbers. Confirmed independently: 29,619 of 29,664 rows on a real store are
  out of range. Pre-existing and unrelated to this PR; it needs its own issue.
  npm run eval:graph -- --validate passes.
• Two test expectations changed because they encoded the defects being fixed,
  not invariants the fix broke. Both are called out in the diff with the
  reasoning, and both now assert the underlying property directly — in
  particular, that an external tsconfig is never read and never becomes graph
  provenance.

Code-graph changes

• This PR targets main
• A linked issue agrees on the bounded extractor/resolver scope
• The change follows the frozen LanguageExtractor or FrameworkResolver interface
• A focused fixture and assertions for the expected node/edge shape are included
• Any new grammar WASM, extension mapping, extractor, or resolver is registered — n/a, none added
• No graph identity, reconciliation, schema, or drift-semantics changes are included