v4_lens_gate root cause: batch discovery resolves (resolve-once), restore 20m timeout

[briansrls]

Root cause

v4_lens_gate spends ~14.5 of its ~18 green minutes inside a single discover_owned_data invocation (CI log: 14m39s silent gap, e.g. run 27376554922). discover_owned_data_decls ran a full compile_to_resolved per candidate claim file — 44 files × ~19s ≈ 14 min — re-resolving nearly identical src/v4 import closures with no sharing. Cost grows linearly with every new unified_claim_* file. PR #4633 introduced this shape and bumped the job timeout 20→35 in the same commit; under runner contention or a binary-cache miss the job blows through 35 minutes, fails, and ci spot rerun re-attempts it up to 3 more times — a load feedback loop.

Fix: resolve-once batched discovery (the #4614 "resolve-once-run-many" pattern)

discover_owned_data_decls now groups candidate entries into collision-free closure groups and runs ONE compile_to_resolved over each group's merged source union. Facts are still read per entry from the typed graph via the unchanged owned_data_decls_for_entry; grouping is pure orchestration over the same resolve + extraction primitives (single-authority preserved — resolve_entry_graph_with_index and the batched path share the extracted resolved_graph_from_sources).

Safety (fail-closed at every step):

• Grouping is conservative: entries whose closures would put two same-named top-level decls (any item kind, scanned at column 0) into one merged resolve are split into separate groups. The name scan is used ONLY for the grouping decision, never as a fact source — facts still come exclusively from the resolved graph. A false negative in the scan still trips the resolver's own registry handling; a false positive only forces a loud extra group.
• Marker-count guard: on the merged path, each entry's resolved unified_claim_* record count must equal its column-0 data unified_claim_ marker count; a shortfall (e.g. a registry collision swallowing a decl) is a hard error instead of a silent miss.
• --max-resolves latency ratchet (new bin flag, wired into scripts/v4-discover-owned-data.sh): if a future decl-name collision forces an extra group split, CI fails with an actionable message — the binary now prints the exact colliding decl name and the two declaring files — instead of silently re-inflating wall-time. Declared-budget-is-a-gate-error per the S3 §3.1 amendment idiom.

Collisions found and resolved

Running the ratchet at 1 surfaced two real bare-name collisions in the corpus:

• mvp1_forbidden_authority_source_text was declared (same name, different files) in each of the five mvp1_*_add_translate.dag manual claim files. Renamed per-language (mvp1_go_…, mvp1_python_…, …) — each decl is file-local, no cross-references, no unified_claim_* records affected.
• type OverflowDisposition is declared in BOTH src/v4/std/integer.dag and src/v4/extdeps/languages/rust.dag. Renaming/unifying that pair is a substrate modeling decision (MODELING.md M9) out of scope for a CI-latency PR, so the ratchet is set to --max-resolves 2 with a comment naming the collision; entries pulling in rust.dag resolve in their own group.

Measured (local, by execution)

• baseline (per-entry, old binary built from the refactor-only commit): 29m22s, 113 records
• batched: 3m11s, 2 graph resolves covering 44 entry files, 113 records — manifest + transport TSV byte-identical to baseline
• full scripts/v4-substrate-equivalence-gate.sh --perturb-check green with the new binaries in 5m54s end-to-end (all three perturb checks still fire)

CI

• v4_lens_gate timeout-minutes restored 35 → 20 (the pre-glob: replace grep+hand-count-pin with discover_owned_data by-execution; delete pin + grep script; consumers count-by-execution #4633 ceiling), with a comment forbidding absorb-the-slow-step raises.

Follow-ups (separate PR): timeout-raise diff gate, spot-rerun timeout-awareness, per-phase gate latency notices.

🤖 Generated with Claude Code