A `tensor_view_2d` with run-time extents accepts any declared shape

Vx#397 made the checker compare a declared tensor shape against the computed one. A view whose extents are literals is compared:

let w = unsafe { tensor_view_2d(pw, 4, 3) };
let bad : Tensor<f32, [9, 9]> = w;     // Error: Type mismatch in variable declaration 'bad'

A view whose extents are run-time values is not:

let n = unsafe { vx_env_args_count() };
let w = unsafe { tensor_view_2d(pw, n, 3) };
let bad : Tensor<f32, [9, 9]> = w;     // accepted, no diagnostic

The second exits 0. This is the same vacuity Vx#397 closed for matmul: when one side carries no comparable dims, is_assignable skips the comparison rather than refusing it, so the annotation is checked against nothing and every later use that trusts [9, 9] is lied to.

Two shapes it could take: reject the declaration outright when the source's dims are not statically known, or accept it as a claim and emit the run-time extent check the declaration then justifies. The first is what a let annotation means elsewhere; the second is what unsafe already means for this call, whose extents are the caller's claim about the pointer either way.

Related: Vx#397 (the same hole for matmul), and the note in Vx#391 about which destinations can be filled in place.

Start by tracing the is_assignable path described in this issue and compare it with the matmul fix from Vx#397. Reproduce the runtime-extents example and determine whether declarations should reject unknown dimensions or emit a runtime check; done means the annotation no longer silently accepts an unchecked shape.