A consumer module's ADT field could reference a kernel-tier
auto-imported type by its bare name in op/value positions
(`(new RawBuf ...)`, `RawBuf.get`) but NOT in the type-constructor
position of the field declaration: `(con RawBuf (con Int))` stayed
the unqualified `RawBuf<Int>` and failed to unify with the
constructor argument's `raw_buf.RawBuf<Int>`, so a RawBuf could not
be stored in a user ADT field without spelling the qualified
`raw_buf.RawBuf`.
`qualify_workspace_module` skipped `Def::Type` entirely, and the
`Term::Ctor` arm only qualified field types of cross-module *owning*
types — a *local* type carrying a cross-module field was the
uncovered case. The fix qualifies each ctor field type in the
`Def::Type` arm via the existing `qualify_workspace_types`, which
upgrades only genuinely cross-module type-cons (skips
`own_local_types` and primitives), so a purely-local field is never
spuriously rewritten. This is a check-side workspace transform, not
the on-disk canonical form, so no module hash drifts (both hash-pin
tests stay green).
RED test `rawbuf_in_user_adt_field_resolves_bare_name` in
crates/ailang-check/tests/workspace.rs, with the bare-name fixture
(now checks/builds/runs -> 42, live=0, the ADT drop cascade frees
the buffer slab) and the qualified control twin.
This is the Series-substrate shape (a RawBuf wrapped in a user ADT),
so the inconsistency would have bitten the pending series milestone.
closes#50
Brummel
a92bcaf969