types: a module's interface carries the records and opaque types it references

[simontreanor]

What

ModuleExports held only what a module declares, not what its exports refer to, and two bugs fell out of that gap:

• An extern type cannot be named across a module boundary #72: an extern type could not be named across a module boundary. There was no export slot for opaque handle types, so type Holder = { h: Gen.Rng } failed with unknown type and cascaded into a bogus not a record type on every later use of Holder.
• A record reached only through another module's exports has invisible fields #75: a record reached only through another module's exports had invisible fields. Middle exported Wrap { wConf: Inner.Config }, and a consumer importing only Middle could hold and pass the Config inside but got unknown record field on x.wConf.cSize.

How

The interface now closes over what it references, the same treatment the scheme side got in #26.

• extern type exports as name + arity (ExportedOpaque) and registers in a consumer under its bare identity name and a qualified key, exactly like a sum type, clash check included.

• Records and opaque types mentioned by exported schemes, constructor schemes, or exported record fields are pulled from the imports' interfaces, tagged with the module that declares them, and re-exported (close_over_references). Newly pulled records are walked in turn, so a chain of any depth crosses, and a seen set terminates the walk on mutually referencing records. Each import's interface is itself closed, so one pull per hop reaches everything.

• A carried type registers under its bare identity name only: it can be named, unified, and field-accessed. Constructing it, pattern-matching it, or writing the qualified spelling still requires importing the declaring module directly. By-name field lookup treats carried records as a fallback tier: records declared here or imported directly decide first, and a carried record owns a field only when no record in that tier declares it, so a dependency two hops away can never make a working access ambiguous. Two carried records that alone declare a field still tie, and the ambiguity message names them.

• A carried name already taken (by a local type or a direct import) is skipped silently, since the consumer never wrote that name: local and direct declarations win, and the same record arriving along two import paths (a diamond) is recognized by its declaring module and admitted once. A genuinely shadowed record's fields feed the diagnostics instead:

  unknown record field `cSize`; the record `Config` in module `Inner` declares
  this field, but another type named `Config` is already in scope here, so that
  record is hidden
  

  and constructing or matching a carried record bare is refused with the fix spelled out: the record `Config` is declared in module `Inner`; import `Inner` to construct its values here (the pattern site says "to match"). A name that is no record at all keeps "not a record type".

• The lowering side keeps up: a record update in a consumer that never imports the declaring module reconstructs via that module's class (inner.Config(...), with import inner hoisted). ModuleExports::carried_records feeds the project driver's per-module ImportContext, and record_class_name accepts the carried modules.

• A genuinely unknown qualified type still reports one clean unknown type error, covered by a test.

DESIGN.md §6.1 and INTERNALS.md describe the closure and the name rules; the stale ExportedType doc comment about records/measures/externs is corrected.

Tests

New in tests/project.rs: both issue repros end to end (e2e_an_extern_type_can_be_named_across_the_module_boundary, e2e_a_transitive_record_field_is_accessible), updates through the boundary, depth 3, a record cycle, the direct-over-carried field precedence (including the breaking program from review, end to end), carried-vs-carried ambiguity, the shadowed-name hint, the diamond, direct-plus-carrier coexistence, construction refusal without a direct import (qualified, and bare with the construct/match messages), bare naming of a carried opaque type, the opaque clash check, and the clean unknown-type error.

cargo test, cargo clippy --all-targets, and cargo fmt --check are clean.

Closes #75
Closes #72