P3a-1: eliminate three production self-fork homonyms (KeySource, JsonValue, YamlValue)

[briansrls]

Summary

Eliminates three measured production self-fork homonyms surfaced by the namespace-only binding rule: two declarations sharing an unqualified type name in one closure now refuse instead of pool-coincidence binding.

The whole-corpus census cannot prove any production pair is genuinely co-resolved in a real closure — the synthetic root forces everything together. The authoritative ambiguity population comes later from the compiler fold over real closures. These three renames are safe because they are live production carriers with verified overlapping consumers, not because the census count alone established co-resolution.

None of the five P3a-1 families were byte-structurally equivalent, so mechanical delete-and-repoint was unsound everywhere. This PR applies homonym elimination (rename) only where production modules diverge:

• KeySource — v2 substrate carrier SubstrateKeySource (std.effects.KeySource keeps the name; String-vs-Symbol unification stays grants-lane)
• JsonValue — v2 grammar witness JsonSchemaCarrierValue (extdeps.languages.json.emit.JsonValue keeps production emission; List-vs-Map object representation is a separate format-design lane)
• YamlValue — v2 grammar witness YamlSchemaCarrierValue (extdeps.languages.yaml.types.YamlValue keeps workflow YAML)

HOLD (no rename) — measurement artifacts from the forced whole-corpus closure, not production co-resolution defects:

• Bit — fixture-vs-fixture (nest_d1..d4 each declare type Bit = B0 | B1 in four modules that never co-resolve). A shared rename (e.g. MechanismBit) is ineffective: the diagnostic is on variant names B0/B1, not the type name — collision survives verbatim. Four distinct names would change the outcome but is churn; under namespace-only, nest_d1.Bit vs nest_d2.Bit differ and the collision dissolves for free.
• Condition — independent example modules (interp_test, weather) that never import each other. Distinct renames would technically clear it but are the same artifact class.

Disposition recorded in gunbc.p3a1_self_fork_homonym_disposition carrier notes.

No alias keeps the bare name as a second namespace candidate.

Test plan

• Grep verification: no type KeySource in v2.std.effects; no v2 JsonValue/YamlValue type decls outside note strings
• CI floor (dag compile-clean + affected witnesses)

[gunbai-bot]

Response to review 45577 (codex REQUEST_CHANGES on variant-level homonyms)

The Bit hold note is being read across a scope boundary. It documents why a shared type rename fails for four fixtures that all declare type Bit = B0 | B1 — the VariantCollision diagnostic names the variant (B0), and the enclosing type name stays Bit in all four, so one shared rename cannot work.

P3a-1's measured rows for JsonValue, YamlValue, and KeySource were duplicate unqualified type declarations across the dag/ production tree and the src/v2/ substrate fork (type JsonValue in both extdeps.languages.json.emit and v2.extdeps.formats.json, etc.). This PR eliminates that class: production carriers keep the bare name; v2 witnesses get distinct outer types (JsonSchemaCarrierValue, YamlSchemaCarrierValue, SubstrateKeySource).

Shared variant spellings (JsonNull, PathParam, …) are a different mechanism. VariantCollision is raised per module when that module's flat constructor namespace (locals + direct imports) binds one arm name to two owners — see constructor_owner_ruling_test.rs cross_import_arm_collision_is_a_typed_error. It is not a whole-closure census over modules that never import each other.

Verified on current head:

• Zero .dag modules directly import both extdeps.languages.json.emit and v2.extdeps.formats.json (or both yaml.types and v2.extdeps.formats.yaml).
• v2.std.effects imports std.effects without KeySource / PathParam / InputField; only SubstrateKeySource contributes those arms locally.
• v2 consumers (openapi, json_schema) use JsonSchemaCarrierValue / YamlSchemaCarrierValue as field types only — no bare JsonNull / YamlNull construction sites in the v2 subgraph.

So the outer-type rename does collapse the measured duplicate-type homonym for this lane. Renaming every shared variant arm would be carrier unification / format-design work (parent explicitly scoped List-vs-Map object representation out of this PR), not the homonym-rename slice.

Recorded in gunbc.p3a1_self_fork_homonym_disposition p3a1_variant_vs_type_homonym_note (commit d65ab3b).