fix(ir): array-dim/count path joins the unified float→int rule — all 5 sites consistent [F0.11]

The compile-time count fold (array dimension / Vector lane / value-param) was
integer-only: it folded a DIRECT integral float literal (`[4.0]`, `[N]` with
`N : f64 : 4.0`) but rejected an INTEGRAL expression built from a non-integral
float-const leaf (`[F + 1.5]` = 4.0, `F : f64 : 2.5`) — and a const folded from
one (`[K]` with `K : s64 : F + 1.5`) — as "must be a compile-time integer
constant". This was the last of issue 0095's five narrowing sites (local /
field / param / const / array-dim) still diverging.

Route the count fold through the SAME compile-time float evaluation the other
four sites use:

- New `program_index.foldCountI64` — the single int-or-integral-float count
  fold: `evalConstIntExpr` first, then (only on failure) `evalConstFloatExpr` +
  `floatToIntExact`. `foldDimU32` (dim/lane/u32 value-param), the non-u32
  value-param gate, and `emitModuleConst`'s integer-const materialization all
  delegate to it, so a const's emitted value and its use as a count come from
  one fold (no parallel integral check, no two-resolver divergence — issue 0083).
- New `DimU32.non_integral_float` variant carries a non-integral float dim to a
  distinct, accurate diagnostic ("array dimension must be an integer, but '2.75'
  is a non-integral float") — the cast-escape advice the binding sites give does
  not apply in a count position, so the dim wording omits it. `reportDimError`,
  the Vector-lane resolver, and the top-level array-alias diagnostic all handle
  the new variant, so the DIRECT and type-ALIAS forms emit the identical message.
- `type_bridge.StatelessInner.lookupFloatName` (via `moduleConstFloat`) is the
  float twin of its `lookupDimName`, so the registration-time alias path folds a
  float-const-leaf dimension to the SAME count as the stateful direct path.

`inline for` range bounds are spec endpoints, not counts (specs.md §2), so they
keep the int-only fold deliberately (no silent-truncation bug there).

Relaxes the F0.4 `examples/1132` wording: a non-integral float const dim now
reports the precise "non-integral float" message (it still errors).

Regression: 0168 (positive — `[F + 1.5]s64`, `[KF]s64`, alias `ArrFE` all fold
to len 4), 1146 (negative — `[F + 0.25]s64` errors), 1132 (precise wording), and
a `foldCountI64`/`foldDimU32` unit test. issues/0095 marked RESOLVED (attempt 4).
specs.md + readme.md state the unified rule across all five sites.

specs.md

@@ -891,10 +891,16 @@ MyArr :: Array(5, s32);   // equivalent to [5]s32
 
 A **count** is a compile-time integer used as an array dimension, a `Vector`
 lane count, or a generic value-param count. Every count must be **integral**: an
-integral float (`4.0`, or a float-typed const `N : f64 : 4.0`) folds to its
-integer (`[4.0]s64` ≡ `[4]s64`), while a non-integral float (`4.5`) is rejected.
-This is the same integral-float rule a typed binding's float→integer initializer
-follows (see "Implicit float → integer", §2 Type Conversions).
+integral compile-time float folds to its integer (`[4.0]s64` ≡ `[4]s64`), while a
+non-integral float is rejected (an array dimension reports "array dimension must
+be an integer, but '4.5' is a non-integral float"). This holds however the float
+is written — a literal (`4.0`), a float-typed const (`N : f64 : 4.0`), or a
+const **expression** whose value is integral, including one built from a
+non-integral float-const leaf (`F : f64 : 2.5; [F + 1.5]s64` ≡ `[4]s64`, and
+likewise through a const, `K : s64 : F + 1.5; [K]s64`). A count and a typed
+binding's float→integer initializer share the *same* compile-time float
+evaluation, so they agree at every site — direct, through a const, or via a type
+alias (see "Implicit float → integer", §2 Type Conversions).
 The accepted *range* of a count is **context-dependent** — zero is legal for
 some counts and not others:
 
@@ -1438,10 +1444,15 @@ array dimension / lane count uses (see "Array dimensions are integral", §2):
   "cannot implicitly narrow non-integral float '…' to 's64'; use an explicit
   cast (`xx`/`cast`)".
 - This applies uniformly to a typed **local**, a function **param default**, a
-  struct **field default**, a call **argument**, and a typed module **constant**
+  struct **field default**, a call **argument**, a typed module **constant**
   (`K : s64 : 4.0` → 4; `K : s64 : M + 2.0` → 4; `N : s64 : 1.5` and
-  `N : s64 : M + 0.5` → error). A **runtime** float (one with no compile-time
-  value) is unaffected — narrow it explicitly with `xx`/`cast`.
+  `N : s64 : M + 0.5` → error), and an array **dimension** / count (`[F + 1.5]s64`
+  ≡ `[4]s64`; `[F + 0.25]s64` → error). All five sites fold the *same* set of
+  compile-time float expressions through one evaluator — only the dimension/count
+  site phrases its rejection as "array dimension must be an integer, but '…' is a
+  non-integral float", since the `xx`/`cast` escape does not apply in a count
+  position. A **runtime** float (one with no compile-time value) is unaffected —
+  narrow it explicitly with `xx`/`cast`.
 
 **Explicit (narrowing)** — requires `xx` prefix (or `cast(T)`):
 - Integer to narrower integer (`s32` → `u8`)