fix(ir): complete const-float evaluator — resolve float-const leaves too [F0.11]

Completes issue 0095: a non-integral float→int narrowing via a FLOAT-const
leaf (`F : f64 : 2.5; y : s64 = F + 0.25` = 2.75) silently truncated to 2.
`evalConstFloatExpr` delegated only INTEGER leaves to `evalConstIntExpr` and
had no float-const leaf arm, so the unified rule never saw the value.

- program_index.zig: add `moduleConstFloat`/`moduleConstFloatFramed` — the f64
  twin of `moduleConstInt` (same `isCountableConstType` gate, same cyclic-
  definition frame), recovering a numeric module const's value via
  `evalConstFloatExpr`. Add `lookupFloatName` to `ModuleConstCtx` and the
  `.identifier`/`.type_expr` leaf arms to `evalConstFloatExpr` that call it.
  Integer / integral-float leaves keep resolving through the existing
  `evalConstIntExpr` delegation, so the unified rule now applies to ANY
  compile-time-constant float expression — literal, int-const leaf, float-const
  leaf, and combinations — at every binding site.
- lower.zig: add `Lowering.lookupFloatName` delegating to `moduleConstFloat`.
  Route `typedConstInitFits`' integral-fold check through `evalConstFloatExpr` +
  `floatToIntExact` (the SAME facility `foldComptimeFloatInit` uses) instead of
  the int-only `evalComptimeInt`, which folded leaf-by-leaf in i64 and so
  rejected an integral SUM built from a non-integral float leaf
  (`K : s64 : F + 1.5` = 4.0 now folds; `K : s64 : F + 0.25` errors).

A LOCAL `::` const leaf is a scope ref (not in the const tables) so neither
the int nor float evaluator folds it — float now matches int exactly there.

Regression: examples/1146 (negative) + 0168 (positive) extended with
float-const-leaf cases at local/field/param/const; unit test in
program_index.test.zig covers the leaf resolution (F→2.5, F+0.25→2.75,
F+1.5→4.0). specs.md + readme.md state the rule covers any compile-time-const
float expression incl. float-typed const leaves. issues/0095 banner updated.

Gate: zig build + zig build test green; 447 examples pass, 0 failed.

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

@@ -42,15 +42,44 @@
 >   reads `cannot implicitly narrow non-integral float …` instead of the stale
 >   `initializer is a float literal / floating-point expression`.
 >
+> **Completion (F0.11 attempt 3)** — attempt 2 resolved INT-const-expr leaves
+> (`M + 0.5`, `M :: 2`), but a non-integral result via a FLOAT-const leaf
+> (`F : f64 : 2.5; y : s64 = F + 0.25` = 2.75) still truncated silently:
+> `evalConstFloatExpr` delegated only integer leaves to `evalConstIntExpr` and had
+> no float-const leaf arm. Closed by completing the evaluator:
+> - `program_index.moduleConstFloat` — the f64 twin of `moduleConstInt` (same
+>   `isCountableConstType` gate, same cyclic-definition frame), recovering a
+>   numeric module const's value through `evalConstFloatExpr`. A new
+>   `lookupFloatName` ctx method (on `Lowering` and `ModuleConstCtx`) surfaces a
+>   NON-INTEGRAL float const leaf; `evalConstFloatExpr` gained `.identifier` /
+>   `.type_expr` arms that call it. Integer / integral-float leaves keep resolving
+>   through the existing `evalConstIntExpr` delegation, so the unified rule now
+>   applies to ANY compile-time-constant float expression — literal, int-const
+>   leaf, float-const leaf, and combinations — at every binding site.
+> - `typedConstInitFits` now judges integral-fold via `evalConstFloatExpr` +
+>   `floatToIntExact` (the SAME facility `foldComptimeFloatInit` uses) instead of
+>   the int-only `evalComptimeInt`, which folded leaf-by-leaf in `i64` and so
+>   rejected an integral SUM built from a non-integral float leaf
+>   (`K : s64 : F + 1.5` = 4.0). Integral float-const-leaf consts now FOLD;
+>   non-integral ones still error with the unified wording.
+> - Out of scope (consistent with the int evaluator): a LOCAL `::` const leaf is
+>   resolved as a scope ref, not through the const tables, so neither
+>   `evalConstIntExpr` nor `evalConstFloatExpr` folds it — a local `M : s64 : 2`
+>   in `M + 0.5` and a local `F : f64 : 2.5` in `F + 0.25` both still truncate
+>   identically. Float now matches int exactly at that boundary.
+>
 > Regression tests: `examples/0168-types-integral-float-to-int.sx` (positive —
-> 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
+> local/field/param/const fold, integral int-const-EXPRESSION (`M + 2.0`) AND
+> float-const-LEAF (`F + 1.5`, `F : f64 : 2.5`) fold at local/field/param/const,
+> `xx`/`cast` truncate incl. `xx (M + 0.5)` / `xx (F + 0.25)`),
+> `examples/1146-diagnostics-nonintegral-float-to-int.sx` (negative —
+> non-integral LITERAL, int-const-EXPRESSION (`M + 0.5`), AND float-const-LEAF
+> (`F + 0.25`) 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".
+> `program_index.test.zig` "evalConstFloatExpr folds comptime float expressions"
+> (covers the float-const leaf: `F` → 2.5, `F + 0.25` → 2.75, `F + 1.5` → 4.0).
 
 ## Symptom
 A typed LOCAL (and likely typed param/field) silently truncates a floating-point