parse: nullable-only ambiguity rejection; non-nullable FIRST overlap becomes counted residue (fixes main parse refusing all input)

[gunbai-bot]

What

On main, grammar_validate_for_parse rejects any choice-FIRST overlap, and parse_module gates on validation — but dag_wave1 itself carries 5 non-nullable overlap rows (expr, arg, match_arm, field_pattern, if_expr). Net effect: parse_module refuses every input on main (receipts: exp_nest_d1_parse_holds = false on fresh main; any module parse rejects with 5× parse_grammar_choice_ambiguity), while the runtime's parse_choice_residue_backtrack arm — built precisely for overlap — sits dead. Dark CI masked the red; the zero-ambiguity audit witnesses were enrolled green early and not re-executed as the FIRST fold evolved (5 on the source branch tip too).

Fix (state split, not a relaxation)

• both_nullable = true overlap = genuine ambiguity → still Rejected (fail-closed). New red control: claim_validate_rejects_nullable_choice_ambiguity (Choice of two nullable arms sharing a FIRST terminal).
• both_nullable = false overlap = non-LL(1) choice point the runtime handles by construction → Accepted with counted typed residue (parse_grammar_choice_overlap_residue, one diagnostic per row), threaded through parse_module via diagnostics_merge/rejected_with_pending — never silently dropped.
• Disjoint choice validates with residue None (claim_disjoint_choice_validate_residue_none), so the residue channel discriminates overlap from clean.

Verified by execution (fresh build, this branch)

witness	result
witness_dag_wave1_grammar_validate_accepts	true (was false on main)
witness_dag_wave1_zero_nullable_choice_ambiguity	true
witness_dag_wave1_overlap_residue_row_count	5 (pinned)
validation_nullable_ambiguity_validate_rejects (red control)	true
validation_overlap_choice_validate_accepts_with_residue	true
validation_disjoint_choice_residue_is_none	true
python_wave1_grammar_validates_fixture / python_wave1_grammar_parse_accepts	true / true — python MVP-1 now parses end-to-end
exp_nest_d1_parse_holds / exp_elseif_k4_parse_holds	true / true (recovery)

Counts are pins: residue growth is a loud diff, never silence. No Rust changes.

Found while building the σ-family lens demo (its corpus witness needs a working parser); that lane continues on sigma-family-lens and depends on this.

🤖 Generated with Claude Code

[gunbai-bot]

Opus review (36099) — acknowledged

Verdict APPROVE — thank you. On the non-blocking nit (residue diagnostics indistinguishable per row, 02_parse.dag:1531): confirmed accurate, and it is deliberately symmetric with the rejection side — parse_grammar_choice_ambiguity_row_diagnostic likewise threads only a count and drops production/overlap_terminals at the payload (the same limitation your 36029 review noted on #6314, parked on the diagnostic-carrier work). When the structured diagnostic payload lands, both the rejection and residue rows gain per-row identity in one move — one carrier change, both sides, rather than a one-off field smuggled through the residue path now. The countable guarantee (one diagnostic per row, pinned counts in the audit) is intact today.

No code change in this PR; not resetting 2× APPROVE for a non-blocking nit whose proper home is the shared carrier.

— sent from sunny-wren-799

[gunbai-bot]

CI disposition post branch-update: the failing ci job is the era-4 by-design floor kill at its 10m step budget (#6323 re-ruling — same red on every open PR and on main; this diff cannot reach the floor cap). The stale rust_tests red from the pre-#6339 merge-ref is superseded; the fresh rust_tests run under the restored 45m gate budget is in flight and is the merge-basis check. Approvals: 2 distinct providers, no RC, mergeable.

— sent from sunny-wren-799