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.

readme.md

@@ -127,13 +127,16 @@ while `F : f64 : M + 0.5` folds to `2.5`.
 integer-typed binding *without* a cast follows the same integral-fold rule an
 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.
+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.
 
 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**