fix(ir): value-param type functions + range-checked dim/lane fold (0083, 0087)

Two remaining siblings in F0.4's comptime-int path.

1. Type-returning function with a value param used as a TYPE annotation
   (`b : Make(N, s64)` where `Make :: ($K: u32, $T: Type) -> Type`):
   - `isValueParamPosition` (semantic_diagnostics) now also skips a value
     param of a `fn_ast_map` type-returning function, so `N` is not walked
     as the type name "N" ("unknown type 'N'").
   - `resolveParameterizedWithBindings` routes a type-returning-function
     name to `instantiateTypeFunction` (the `.call` path already did).
   - `instantiateTypeFunction` resolves a general return-type expression
     (`return [K]T`) with bindings active — not just struct/union returns.
   `Make(N, s64)`, `Make(M + 1, s64)`, `Make(3, s64)` all resolve to one
   `[3]s64`.

2. Oversized dim/lane fold panicked the compiler (0087): an array dim /
   Vector lane folded to a valid i64 (5e9) then narrowed to u32 with an
   unchecked `@intCast`. New single gate `program_index.foldDimU32` folds
   via `evalConstIntExpr` then range-checks `[min, maxInt(u32)]`; the three
   narrowing sites (resolveArrayLen stateful + stateless, resolveVectorLane)
   all route through it and emit a clean diagnostic + halt instead of
   panicking. Value-param args stay i64 until used as a dim/lane, where the
   same gate checks them.

Regressions: examples/0208 (value-param type function), examples/1130
(oversized array dim clean halt), examples/1503 (oversized Vector lane
clean halt). Marks issue 0087 RESOLVED.

Gate: zig build, zig build test, bash tests/run_examples.sh — 398 passed,
0 failed, 0 timed out.

issues/0083-named-const-array-dimension-miscompiled.md

@@ -103,6 +103,25 @@
 > resolve to the same instantiation as `Vec(3,f32)`),
 > `examples/0610-comptime-inline-for-const-bound.sx` (`inline for 0..M` and
 > `0..(M+1)` unroll).
+>
+> **Value-param type functions + oversized guard (attempt 6).** Two remaining
+> siblings in the comptime-int path. (1) A type-RETURNING function with a value
+> param used as a TYPE annotation (`b : Make(N, s64)` where `Make :: ($K: u32,
+> $T: Type) -> Type { return [K]T; }`) was rejected "unknown type 'N'" because
+> the unknown-type checker walked the value-param position as a type name, AND the
+> parameterized-type-annotation path never routed to `instantiateTypeFunction`
+> (only the `.call` path did), nor did that binder resolve a non-struct/union
+> return shape. Fix: `isValueParamPosition` (semantic_diagnostics.zig) now also
+> skips a value param of a `fn_ast_map` type-returning function (mirroring the
+> binder's value/type classification); `resolveParameterizedWithBindings` routes
+> a type-returning-function name to `instantiateTypeFunction`; and that binder
+> resolves a general return-type expression (`return [K]T`) with bindings active.
+> `Make(N, s64)`, `Make(M + 1, s64)`, and `Make(3, s64)` now resolve to one
+> `[3]s64`. (2) Oversized dim/lane folds (`[5_000_000_000]`) panicked the
+> compiler — fixed under issue 0087 via the shared range-checked
+> `program_index.foldDimU32` gate. Files: `src/ir/semantic_diagnostics.zig`,
+> `src/ir/lower.zig`, `src/ir/program_index.zig`, `src/ir/type_bridge.zig`.
+> Regression: `examples/0208-generics-value-param-type-function.sx`.
 
 ## Symptom
 A fixed array whose dimension is a module-global integer constant (`N :: 16;

issues/0087-oversized-comptime-int-dimension-panics.md

@@ -0,0 +1,64 @@
+# 0087 - oversized compile-time integer in type dimension/lane panics
+
+> **RESOLVED.** Root cause: an array dimension / Vector lane folded to a valid
+> `i64` (e.g. `5_000_000_000`) was then narrowed to `u32` with an unchecked
+> `@intCast` at three sites (`Lowering.resolveArrayLen` lower.zig:11656,
+> `Lowering.resolveVectorLane` lower.zig:11836, `StatelessInner.resolveArrayLen`
+> type_bridge.zig:58), aborting the COMPILER with "integer does not fit in
+> destination type" — the fold was correct, the narrowing was not. Fix: a single
+> range-checked fold-to-u32 gate, `program_index.foldDimU32(node, ctx, min)`,
+> folds via `evalConstIntExpr` then checks `[min, maxInt(u32)]` and returns a
+> tagged `DimU32` (`.ok` / `.not_const` / `.below_min` / `.too_large`). Every
+> dim/lane narrowing now routes through it — no call site does a bare `@intCast`,
+> so an out-of-u32-range dim/lane surfaces a clean diagnostic ("array dimension N
+> does not fit in u32" / "Vector lane count N does not fit in u32") and halts the
+> build (exit 1) instead of panicking. Value-param args stay `i64` until used as
+> a dim/lane, where the same gate checks them. Files: `src/ir/program_index.zig`
+> (`DimU32` + `foldDimU32`), `src/ir/lower.zig`, `src/ir/type_bridge.zig`.
+> Regressions: `examples/1130-diagnostics-array-dim-oversized-u32.sx` (oversized
+> array dim → clean halt) and `examples/1503-vectors-oversized-lane-not-u32.sx`
+> (oversized Vector lane → clean halt).
+
+## Symptom
+An oversized compile-time integer used where the compiler expects a `u32`
+array dimension or Vector lane count panics inside the compiler instead of
+emitting a source diagnostic.
+
+Observed: `@intCast` panics with "integer does not fit in destination type" in
+`Lowering.resolveArrayLen` / `Lowering.resolveVectorLane`.
+
+Expected: compile halts with a normal diagnostic such as "array dimension does
+not fit in u32" / "Vector lane count must fit in u32", and no compiler panic.
+
+## Reproduction
+```sx
+#import "modules/std.sx";
+
+main :: () {
+    a : [5000000000]s64 = ---;
+    print("{}\n", a.len);
+}
+```
+
+Vector lane sibling:
+
+```sx
+#import "modules/std.sx";
+
+main :: () {
+    v : Vector(5000000000, f32) = .[];
+    print("{}\n", v);
+}
+```
+
+## Investigation prompt
+Fix oversized compile-time integer handling for fixed-array dimensions and
+Vector lane counts. Suspected area: `src/ir/lower.zig`
+`Lowering.resolveArrayLen` and `Lowering.resolveVectorLane`, plus the stateless
+adapter in `src/ir/type_bridge.zig` `StatelessInner.resolveArrayLen`. These
+functions fold to `i64` through `program_index.evalConstIntExpr`, then cast to
+`u32` with `@intCast`; values greater than `std.math.maxInt(u32)` panic in the
+compiler. The fix likely needs an explicit range check before every `u32` cast,
+with a diagnostic on the stateful path and null / `.unresolved` propagation on
+the stateless path. Verify both repros exit 1 with source diagnostics and no
+panic, then run `zig build && zig build test && bash tests/run_examples.sh`.