feat(lang): strict numbers in float files; render3d on float

A numbers float file adapts decimal literals to a fixed operand or slot, and refuses to
promote a computed int to a float implicitly: there it is almost always float bits. Explicit
float(x) is always allowed.

render3d's numbers are float, converted by tools/migrate/floatbits.py - a whole-program
inference of which ints carried IEEE bits (union-find over flows, calls, returns, buffers,
nested buffers and lexical scopes) and a rewriter to operators, Math.* and float literals,
with float_bits / float_from_bits left only where bits really cross (runtime scratch
buffers, mixed buffers). Seed regenerated.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

changes/numbers-float-strict.md

@@ -0,0 +1,13 @@
+bump: minor
+type: feat
+**A `numbers float` file is strict about where its numbers come from.** Two rules, both found
+converting a renderer and a game from float bits in an `int` to real floats:
+
+- A decimal literal takes the kind of what it meets. `factor == 0.0` against a `fixed` parameter,
+  `half(3.0)` into a `fixed` one and `var z: fixed = -1.5` are `fixed` literals there, rather
+  than a `fixed` and a `float` that do not mix.
+- A computed integer never becomes a float implicitly. `count < limit` with an `int` on one side
+  and a `float` on the other is an error that asks for `float(x)`: in a file whose numbers are
+  floats, an `int` meeting one is almost always raw bits, and promoting it compares the bits as a
+  number. It caught a uniform fed an integer as float bits, and a test comparing a tint's bits
+  with its value. Integer constants still promote, and `float(x)` is always allowed.