decision: a `[?, ?]` value no longer narrows to a static binding implicitly, and there is no spelling for that narrowing before the tag

ae80cc0d applies the spelling RFC's ⊑ as written: a static extent widens to ?, and ? does not narrow to a static extent without saying so. Before it, a DynTensor source was assignable to any shaped annotation (is_assignable, the old dyn_parts arm), an unchecked narrowing.

The explicit spelling, narrow / narrow_checked, is in the bounded-extents RFC, which is post-launch. So until it lands, the only way to write let c : Tensor<f32, [2, 3]> = a @ b over [?, ?] operands is to annotate the binding [?, ?]. One corpus program relied on the old rule (tests/optimizations/pass/kernel_kind_matmul.vx, now spelled that way).

Options: (a) keep it refused until narrow exists, which is where main is; (b) restore the implicit narrowing as a documented pre-launch exception, with a memref.cast that MLIR accepts but nothing checks; (c) bring a minimal narrow_checked forward. This is a language call.

Start by reviewing the is_assignable logic and its former dyn_parts arm, then inspect tests/optimizations/pass/kernel_kind_matmul.vx and the spelling and bounded-extents RFCs. The issue is currently a language-design decision among three options, so done means an accepted decision is implemented and the affected corpus test and assignment behavior agree with it.