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.

readme.md

@@ -130,13 +130,16 @@ array dimension uses: an **integral** compile-time float folds to its integer, a
 or *any* compile-time-constant float expression — including one that references a
 float-typed const (`F : f64 : 2.5; y : s64 = F + 1.5` → `4`) — and is uniform
 across a typed local, a parameter default, a struct field default, a call
-argument, and a typed constant — `y : s64 = 4.0`, `K : s64 : 4.0`, and
-`y : s64 = M + 2.0` all give `4`, while `y : s64 = 1.5`, `N : s64 : 1.5`,
-`y : s64 = M + 0.5`, and `y : s64 = F + 0.25` (= `2.75`) all error (one wording
-everywhere: `cannot implicitly narrow non-integral float …`). An explicit
-`xx` / `cast(s64)` is the escape hatch and always truncates (`y : s64 = xx 1.5` →
-`1`, `y : s64 = xx (M + 0.5)` → `2`); a genuine runtime float is likewise
-unaffected.
+argument, a typed constant, **and an array dimension / count** — `y : s64 = 4.0`,
+`K : s64 : 4.0`, `y : s64 = M + 2.0`, and `[F + 1.5]s64` (≡ `[4]s64`, whether
+written directly, through a const, or via a type alias) all give `4`, while
+`y : s64 = 1.5`, `N : s64 : 1.5`, `y : s64 = M + 0.5`, `y : s64 = F + 0.25`
+(= `2.75`), and `[F + 0.25]s64` all error (one wording at the binding sites:
+`cannot implicitly narrow non-integral float …`; a dimension instead reports
+`array dimension must be an integer, but '…' is a non-integral float`, since the
+cast escape does not apply in a count position). An explicit `xx` / `cast(s64)`
+is the escape hatch and always truncates (`y : s64 = xx 1.5` → `1`,
+`y : s64 = xx (M + 0.5)` → `2`); a genuine runtime float is likewise unaffected.
 
 Builtin type names (`s2`, `u8`, `bool`, `string`, …) are reserved and a *bare*
 spelling can't be used as an identifier at a **value-binding or declaration-name**