fix(ir): narrow non-integral const-float EXPRESSIONS at typed local/field/param; align const message [F0.11]

Completes issue 0095 (attempt 2). The attempt-1 coerce arm only caught a direct
`const_float` literal, so a non-integral const-folded float EXPRESSION still
truncated silently at a typed local / field default / param default:

  M :: 2;
  local : s64 = M + 0.5;   // → 2  (silent truncation — BUG; now ERRORS)
  fld   : s64 = M + 0.5;   // field default — same
  take(x : s64 = M + 0.5)  // param default — same

while the typed-CONST site already errored. The integral expression
(`M + 2.0` → 4) folded but the runtime/explicit-cast paths must stay untouched.

Fix:
- New `program_index.evalConstFloatExpr` — the f64 counterpart to
  `evalConstIntExpr`, delegating every integer subtree back to it (no parallel
  integer logic) and adding only the float literal / unary-negate / `+ - * /`
  arms. Pure (no diagnostics, no resolution side effects).
- `Lowering.foldComptimeFloatInit` applies the unified rule to a typed-binding
  initializer EXPRESSION: an integral comptime float folds to its `constInt`, a
  non-integral one errors, a genuine runtime float / `xx`-cast falls through to
  the normal path. It runs `evalConstFloatExpr` FIRST (pure) so a `$pack[i]`
  argument is never spuriously type-resolved outside an active binding, then
  gates on `isFloat(inferExprType)` so a plain comptime int is left alone.
  Wired into the typed-local path, the three struct field-default sites (via a
  shared `lowerCoercedDefault`), and the call-argument loop (covers expanded
  param defaults).
- One `Lowering.diagNonIntegralNarrow` now emits the narrowing wording at all
  five sites (coerce arm, global init, const-expr value, the typed-binding
  sites, and the typed-const path). The typed-CONST non-integral diagnostic
  therefore reads "cannot implicitly narrow non-integral float …" instead of
  the stale "initializer is a float literal / floating-point expression".

Tests: examples/1146 (negative) extended with non-integral const-EXPRESSION
cases at local/field/param; examples/0168 (positive) extended with integral
const-EXPRESSION folds and `xx (M + 0.5)` truncation; examples/1143 reconciled
to the aligned const message (G/BAD/BAD2 stay errors); unit test
`evalConstFloatExpr folds comptime float expressions`. Full gate green (447).

issues/0095-typed-local-float-int-narrowing.md

@@ -9,7 +9,7 @@
 > dim — all reusing the single `program_index.floatToIntExact` /
 > `evalConstIntExpr` facility (no second integral check).
 >
-> Fix (`src/ir/lower.zig`, `src/ir/module.zig`):
+> Fix (`src/ir/lower.zig`, `src/ir/module.zig`, `src/ir/program_index.zig`):
 > - `Builder.constFloatInfo` reads a compile-time `const_float` back from its
 >   Ref (value + span).
 > - `coerceToType` now means IMPLICIT coercion: its `.float_to_int` arm folds an
@@ -24,11 +24,33 @@
 >   / `constExprValue` / `globalInitValue` fold an integral float to its int and
 >   reject a non-integral one.
 >
+> **Completion (F0.11 attempt 2)** — the direct-`const_float` coerce arm only
+> caught a float LITERAL; a non-integral const-folded float EXPRESSION
+> (`local/field/param : s64 = M + 0.5`) still truncated silently. Closed by:
+> - New `program_index.evalConstFloatExpr` — the f64 counterpart to
+>   `evalConstIntExpr`, delegating every integer subtree back to it (no parallel
+>   integer logic), adding only the float literal / negate / `+ - * /` arms.
+> - `Lowering.foldComptimeFloatInit` routes the typed LOCAL, struct FIELD
+>   default, and call ARGUMENT (incl. an expanded param default) through
+>   `evalConstFloatExpr` + `floatToIntExact`: an integral comptime float folds,
+>   a non-integral one errors, a genuine runtime float / `xx` cast is left to the
+>   normal path. (Run pure `evalConstFloatExpr` FIRST so a `$pack[i]` arg isn't
+>   spuriously type-resolved out of binding.)
+> - One `Lowering.diagNonIntegralNarrow` now emits the narrowing wording at all
+>   five sites (coerce arm, global init, const-expr value, the typed-binding
+>   sites, and the typed-const path), so the typed-CONST non-integral diagnostic
+>   reads `cannot implicitly narrow non-integral float …` instead of the stale
+>   `initializer is a float literal / floating-point expression`.
+>
 > Regression tests: `examples/0168-types-integral-float-to-int.sx` (positive —
-> local/field/param/const fold, `xx`/`cast` truncate), `examples/1146-diagnostics-
-> nonintegral-float-to-int.sx` (negative — local/param/field error), plus the
-> integral-float const cases added to `examples/0162-types-typed-module-const-
-> roundtrip.sx`. Non-integral const cases in `examples/1143` stay errors.
+> local/field/param/const fold, integral const-EXPRESSION (`M + 2.0`) folds,
+> `xx`/`cast` truncate incl. `xx (M + 0.5)`), `examples/1146-diagnostics-
+> nonintegral-float-to-int.sx` (negative — non-integral LITERAL and const-
+> EXPRESSION error at local/param/field), the integral-float const cases in
+> `examples/0162-types-typed-module-const-roundtrip.sx`, and the aligned const
+> diagnostic in `examples/1143-diagnostics-typed-module-const-mismatch.sx`
+> (G / BAD / BAD2 stay errors with the new wording). Unit:
+> `program_index.test.zig` "evalConstFloatExpr folds comptime float expressions".
 
 ## Symptom
 A typed LOCAL (and likely typed param/field) silently truncates a floating-point