iter ctt.1: env-overlay shape ratification + DuplicateCtor pin

docs/DESIGN.md

@@ -1956,6 +1956,35 @@ with exactly one dot in the name is a qualified reference: `<prefix>.<def>`.
 Hash stability: no new AST node, no renamed fields — all previous module
 hashes stay bit-identical.
 
+## Env construction
+
+The check environment carries two parallel per-module overlays for
+ADT definitions: `env.types: IndexMap<String, TypeDef>` is the
+**owning index** — it stores the full definition keyed by bare type
+name. `env.ctor_index: IndexMap<String, CtorRef>` is the **reverse
+index** — it maps each constructor name back to its owning type, so
+ctor-by-name lookups run in O(1) rather than searching every type's
+ctor list.
+
+The split is not a refactor wart. The two maps have distinct
+semantic roles: an owning data index, and a derived lookup
+accelerator over the same data. Collapsing them into one
+variant-keyed map (`Map<Name, EntryKind>`) would force every
+type-iterator and every ctor-lookup site to discriminate the variant
+tag, reversing the optimisation the reverse index exists to
+provide.
+
+The check-side per-module rebuild of both overlays at
+`crates/ailang-check/src/lib.rs:1342-1384` is intentionally
+retained: the in-band `DuplicateCtor` diagnostic at the same site
+consumes the rebuilt per-module `env.ctor_index`. The mono-side
+overlay was narrowed to types-only at iter ct.3.2 because its
+consumer is the runtime ctor lookup, which became type-driven
+post-ct.2.2 — a different consumer story, hence a different
+overlay shape. The asymmetry between the check side and the mono
+side is by design and is pinned by
+`crates/ailang-check/tests/duplicate_ctor_pin.rs`.
+
 ## Data model
 
 The on-disk JSON-AST is what the toolchain hashes, typechecks, and