compiler: fail closed before codegen when unresolved or dropped types survive type checking

[slepp]

Summary

I want the checker -> serializer -> codegen boundary to fail closed when type information is incomplete, instead of degrading into warnings, omitted expression-type entries, or MLIR fallback behavior.

Why

A few current seams point at the same foundation gap:

• type checking does not appear to guarantee that every surviving expression type is free of unresolved inference variables
• serializer enrichment can drop unconvertible expression types and keep going
• MLIR lowering still has fallback paths when type metadata is missing

We already fixed narrower cases like the old range warning in #264, but the broader issue is that lowering-relevant type facts are not mandatory all the way through the pipeline.

What I want

• if an unresolved inferred type survives past type checking, the compiler should reject it before codegen
• if enrichment cannot serialize a lowering-relevant type, that should be a hard compiler error rather than a best-effort omission
• missing expression-type metadata should be treated as a compiler bug or fail-closed condition at the lowering boundary, not a cue to rediscover type truth heuristically

Scope

This is not a request to redesign the type system. I want a narrower foundation pass that tightens the fail-closed boundary between hew-types, hew-serialize, and hew-codegen.

Acceptance shape

If this gets picked up, I would expect:

1. one explicit invariant for what must be fully resolved before serialization/codegen
2. targeted tests that prove unresolved type holes do not reach MLIR/LLVM
3. fewer silent drops and sentinel fallbacks in the lowering path

Related

This is related to the narrower range warning that was previously tracked in #264, but it is meant to cover the broader checker-to-codegen contract.

[slepp]

Scoping note from the current boundary audit:

• bullet 1 (unresolved inference variables surviving type checking) is already covered by the checker output-contract work on main
• bullet 2 is the next concrete slice: TypeExprConversionKind::Unsupported is still non-fatal in hew-cli/src/compile.rs (inferred_type_serialization_diagnostic_is_fatal), so serializer-side Unsupported conversions can still degrade into warnings instead of aborting
• the same slice should also tighten validate_checker_output_contract so fn_sigs carrying Ty::Error do not survive into serialization/codegen
• bullet 3 (MLIR fallback paths when type metadata is missing) is being narrowed separately by the explicit type-hint cleanup wave

So the next bounded PR for this issue is: make Unsupported fatal at the serializer boundary and prune Ty::Error-bearing signatures at the checker output contract.