Wire points-to solver MAX_SOLVER_ITERATIONS through DEFAULTS.analysis.pointsToMaxIterations

[carlos-alm]

Context

GAUNTLET audit (rule 7, pillar II, warn-level) flagged that MAX_SOLVER_ITERATIONS = 50 in src/domain/graph/resolver/points-to.ts (line 41) is a hardcoded constant that duplicates DEFAULTS.analysis.pointsToMaxIterations in src/infrastructure/config.ts, despite both files' own comments acknowledging the duplication:

• points-to.ts: "Mirrors DEFAULTS.analysis.pointsToMaxIterations in config.ts. TODO(Phase 8.3): thread config through buildPointsToMap so this can be tuned per-repo via .codegraphrc.json"
• config.ts: pointsToMaxIterations is marked @reserved — currently not wired to either the WASM solver (MAX_SOLVER_ITERATIONS in points-to.ts) or the native Rust solver (MAX_SOLVER_ITERATIONS in stages/build_edges.rs), both of which use the same hardcoded value of 50.

Why this is a separate issue, not part of the phase-20 forge commit

Titan-forge phase 20 addresses GAUNTLET FAIL-level complexity findings scoped to exactly 3 files (points-to.ts, ts-resolver.ts, strategy.ts). Actually wiring this constant requires threading a config value through the full call chain:

buildPointsToMap (points-to.ts)
  ← buildPointsToMapForFile (src/domain/graph/builder/stages/build-edges.ts:985)
    ← buildCallEdgesJS (build-edges.ts:818)
      ← buildCallEdgesPhase (build-edges.ts:2133)

...and, per the config.ts comment, a matching change to the native Rust solver (MAX_SOLVER_ITERATIONS in crates/codegraph-core/src/domain/graph/builder/stages/build_edges.rs) to keep both engines in sync (per this repo's dual-engine parity requirement).

That's a multi-file, multi-signature architecture change spanning both the WASM and native engines — out of scope for a decomposition-only forge commit in a file explicitly flagged for "elevated care" due to a history of subtle points-to/resolution correctness bugs. Filing separately so it can be reviewed and tested as its own concern.

Suggested fix

1. Add a maxIterations parameter (defaulting to DEFAULTS.analysis.pointsToMaxIterations) threaded through buildPointsToMap → buildPointsToMapForFile → buildCallEdgesJS → buildCallEdgesPhase.
2. Wire the equivalent value through the native Rust solver's call chain in build_edges.rs.
3. Add a regression test asserting both engines pick up a non-default .codegraphrc.json override identically.

Default value stays 50 either way, so this should be behavior-preserving for all existing repos — the risk is purely in getting the plumbing right, which is why it deserves its own PR and test pass rather than being bundled into a mechanical decomposition commit.