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.

src/ir/program_index.test.zig

@@ -111,6 +111,14 @@ const DimCtx = struct {
         if (std.mem.eql(u8, name, "xs")) return 3;
         return null;
     }
+    // `F` stands in for a NON-INTEGRAL float module const (`F : f64 : 2.5`): the
+    // int folder cannot resolve it, so only the float-leaf lookup surfaces it.
+    // Integer consts (`M`/`N`) are resolved by the int delegation and never reach
+    // this arm; `Z` is genuinely runtime.
+    pub fn lookupFloatName(_: DimCtx, name: []const u8) ?f64 {
+        if (std.mem.eql(u8, name, "F")) return 2.5;
+        return null;
+    }
 };
 
 fn nLit(v: i64) ast.Node {
@@ -345,6 +353,21 @@ test "evalConstFloatExpr folds comptime float expressions, halts on runtime leav
     var neg = nNeg(&mp);
     try std.testing.expectEqual(@as(?f64, -4.5), eval(&neg, ctx));
 
+    // A NON-INTEGRAL float-const leaf (`F : f64 : 2.5`) resolves through the
+    // float-leaf lookup — the int folder cannot fold it (2.5 is not integral), so
+    // an expression like `F + 0.25` (= 2.75) is now recognised as a compile-time
+    // float and rejected by the narrowing rule instead of silently truncating;
+    // `F + 1.5` (= 4.0) is integral and folds. This completes the evaluator for
+    // float-const-leaf expressions (issue 0095, attempt 3).
+    var f = nIdent("F");
+    var quarter = nFloat(0.25);
+    var three_half = nFloat(1.5);
+    var fq = nBin(.add, &f, &quarter);
+    var fh = nBin(.add, &f, &three_half);
+    try std.testing.expectEqual(@as(?f64, 2.5), eval(&f, ctx));
+    try std.testing.expectEqual(@as(?f64, 2.75), eval(&fq, ctx));
+    try std.testing.expectEqual(@as(?f64, 4.0), eval(&fh, ctx));
+
     // A runtime operand poisons the whole fold; a non-arithmetic operator and a
     // float division by zero are not compile-time float leaves → null.
     var zp = nBin(.add, &z, &half);