feat(config): dataflow tiers — close non-literal keys over the L3 DDG and L4 call graph

[rahlk]

Closes #236. Stacked on #233 (base is feat/issue-232-config-read-literal-tier, not main). Spec: codellm-devkit/.github docs/design/specs/2026-09-07-java-config-reads-and-entrypoint-report.md (D30, tiers), epic codellm-devkit/.github#62.

What

The literal tier resolves a read only when the key is a string literal at the call site. Everything else was reason="non-literal", which on real code is the common shape:

String key = "spring.datasource.url";
env.getProperty(key);                                       // L3 closes this

String read(String name) { return System.getenv(name); }    // L4 closes this

Two tiers, gated on the overlays each needs, reading only what the analyzer already emits — no new dataflow machinery:

• L3 intra — a bare-name key closes when every DDG-reaching definition at the call site is the same single string literal.
• L4 interprocedural — a key naming a parameter closes when the callable never rebinds it and every call site targeting it supplies the same literal, directly or through one caller-side hop of the intra tier.

The refusals are the interesting part

A tier that closes a read it should not have emits an edge claiming code reads a key it never reads — strictly worse than the unresolved record it replaced. Three guards, each with a paired test:

1. Any non-closing reaching def kills the resolution, rather than being skipped. Two paths assigning different literals means the read is genuinely ambiguous, and picking one would be a confident wrong answer.
2. The ssa filter keeps -a 3 ⊆ -a 4 true, and is not optional. At -a 4, L4WalaOverlays.java:201 adds points-to prov and mints alias-widened edges. An alias edge can connect this variable's use to an unrelated write that is not a name = "literal" shape — and because a non-closing def kills resolution, letting one in would remove an edge the ssa-only L3 set resolved cleanly. A widening that breaks monotonicity. codeanalyzer-python documents hitting this first.
3. An incomplete call-site set does not close. Known ceiling, stated rather than papered over: a public method can be called from outside the analyzed project, which no in-project call graph rules out — the same whole-application assumption python's tier makes.

Two details worth a reviewer's eye

Span containment, not id equality. The CFG/DDG is statement-level while a call body node is keyed by its own narrower span, so a def's recorded use site is the enclosing statement. Containment covers both the bare-expression-statement case and the common return env.getProperty(key); nesting without special-casing either.

prov means two different things by design. On an edge it is the tier that closed it, so a literal-tier edge still reads ["literal"] at -a 4. On an unresolved record it is every tier attempted, so a failure says how hard the analyzer tried.

Verification

daytrader8, -a 1 vs -a 4 --no-build --no-rta:

edge set	-a 4 is a superset of -a 1 — nothing lost
literal edges	15, still prov: ["literal"] at level 4
unresolved	12, moved to prov: ["literal", "dataflow"]
spurious edges	none — the interprocedural tier added nothing across the corpus
schema	-a 4 payload validates

ConfigDataflowTierTest (11 tests) covers each closure paired with the ambiguous shape that must stay unresolved, the level chain as set containment, and provenance at every level.

Full suite: 539 tests, 1 failure — CodeAnalyzerIntegrationTest cannot reach a Docker daemon here and fails identically on a clean main.

Not verified here

The tiers add nothing on the available corpora. daytrader8's config reads are all either literals or undeclared keys — it contains no non-literal read to widen — and the other checked-in fixtures (plantsbywebsphere, cargotracker, commons-lang, spring-petclinic) have no config reads or no sources at all. So the corpus runs prove monotonicity and no false positives; the closures themselves are proven by fixtures only.

--l3-engine wala was not exercised, since it needs a built project and these runs are --no-build. That is the configuration where guard 2 above actually matters, so it is worth running once against a real build before this merges.