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.

specs.md

@@ -1428,10 +1428,13 @@ array dimension / lane count uses (see "Array dimensions are integral", §2):
 
 - An **integral** compile-time float **folds** to its integer, whether written
   as a literal or a const expression: `y : s64 = 4.0` ≡ `y : s64 = 4`,
-  `n : s64 = -2.0` ≡ `-2`, `y : s64 = M + 2.0` → 4 (`M :: 2`).
+  `n : s64 = -2.0` ≡ `-2`, `y : s64 = M + 2.0` → 4 (`M :: 2`). A const expression
+  here is *any* compile-time-constant float expression — an integer-const leaf
+  (`M + 2.0`), a float-typed const leaf (`F : f64 : 2.5; y : s64 = F + 1.5` → 4),
+  or any combination of them.
 - A **non-integral** compile-time float — literal OR const expression — is a
   **compile error** with one uniform wording at every site:
-  `y : s64 = 1.5` and `y : s64 = M + 0.5` both →
+  `y : s64 = 1.5`, `y : s64 = M + 0.5`, and `y : s64 = F + 0.25` (= 2.75) all →
   "cannot implicitly narrow non-integral float '…' to 's64'; use an explicit
   cast (`xx`/`cast`)".
 - This applies uniformly to a typed **local**, a function **param default**, a