service_realization: keyword parameter then -> proceed (N7 native parse refusal)

[gunbai-bot]

What

v2.compiler.service_realization was a native file refusal in N7's closure (parse_g0_tokens_remain, census run 37197235156, no locus given).

Location. I ran v2.compiler.parse_acceptance_census parse_acceptance_census_for_paths on the file, remotely, and it refused at bytes 18350..18351. That is the ( in ShapeConj => then() inside realization_require_conj.

Root cause (DESIGN §6b)

realization_require_conj named a parameter then and called it. then is a reserved keyword (^dag_token_kw_then in v2.extdeps.languages.dag, and also in extdeps.languages.dag.syntax). The v1 seed lexes it as an identifier, so every seed-interpreted claim stayed green. The v2 grammar refuses it, and v2 is correct to: a keyword is not an identifier.

The earliest unjustified boundary is therefore the source, not the grammar. This is the same class as the second shape of gunbc.recurring_failure_mode seed_admits_a_keyword_as_a_pattern_binder (the loop parameter, #13028). Renaming the spelling is the repair, not a respelling around a parser gap. The grammar is unchanged, so there is no new production and no grammar_choice_ambiguity_roster row, and stern-bear-500 needed no coordination.

Changes

• Renamed the parameter then to proceed, at its four argument labels and in the comment.
• Added the specimen as a receipt on seed_admits_a_keyword_as_a_pattern_binder.

Evidence (all run remotely on BuildBuddy)

• Native parse, before: src/v2/compiler/service_realization.dag refused parse_g0_tokens_remain 18350..18351
• Native parse, after: src/v2/compiler/service_realization.dag accepted
• Claims: I ran service_realization_conformance_test (14) and service_realization_lowering_test (4) with claim_batch. The count is in a follow-up comment.
• Per-file native resolve (reference_conservation_census): the result is in a follow-up comment.
• Not done here: re-running the dependency/native census needs a CI or manager run.

Freeze: this PR needs no floor_cross_claim_pure_producers_warm row.

🤖 Generated with Claude Code

[gunbai-bot]

Evidence results (BuildBuddy, head 0ba2ae3):

• claim_batch over service_realization_conformance_test (14 claims) and service_realization_lowering_test (4 claims): 18 PASS, rc 0.
• reference_conservation_census_for_paths on the file: authored=1721 conserved=0 refused=1095 import_channel=132 dropped=626 unmeasured=94, and every row is refusal-not-at-or-above the module header. So once parse is accepted, a module-level refusal still stands after it. This instrument does not print that refusal's cause. I am not claiming the file resolves natively until the census re-run (or a normalize probe) names that cause.