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).

readme.md

@@ -125,13 +125,15 @@ while `F : f64 : M + 0.5` folds to `2.5`.
 
 **Float → integer narrowing (unified rule).** A float flowing into an
 integer-typed binding *without* a cast follows the same integral-fold rule an
-array dimension uses: an **integral** float folds to its integer, a
-**non-integral** float is a compile error. This is uniform across a typed local,
-a parameter default, a struct field default, and a typed constant —
-`y : s64 = 4.0` and `K : s64 : 4.0` both give `4` (and `K : s64 : M + 2.0` folds
-to `4`), while `y : s64 = 1.5` and `N : s64 : 1.5` both error. An explicit
-`xx` / `cast(s64)` is the escape hatch and always truncates (`y : s64 = xx 1.5`
-→ `1`).
+array dimension uses: an **integral** compile-time float folds to its integer, a
+**non-integral** one is a compile error. It holds whether the value is a literal
+or a const expression, 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`, and `y : s64 = M + 0.5` 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.
 
 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**