_offc_probe_f32equiv.nx

_offc_probe_f32equiv.nx -- IS THE HARDWARE f32 INTRINSIC BIT-IDENTICAL TO THE SOFTWARE HELPER? (2026-08-23) WHY. Measured this session: NishiLang has float TYPES and float LITERALS and a KAT-gated SSE backend, but NO float OPERATORS -- every one of the 17 `emit_f32` sites in nx_parse.nx is an INTRINSIC dispatch (__f32_add/__f32_mul/__f32_div/...). So organs reach for the SOFTWARE helper nx_f32_add (a full IEEE-754 adder written in integer arithmetic) while the HARDWARE __f32_add sits one intrinsic away. A banked measurement puts that software path at 10x/9x/1.6x slower than its twin. THE CHEAP WIN, IF IT HOLDS: re-point the nx_f32_* helper BODIES at the __f32_* intrinsics. That is a LIBRARY change -- zero call-site edits, no nx_parse.nx touch -- and every existing consumer gets the hardware path for free. THE PRECONDITION, AND THE POINT OF THIS PROBE: the two paths must agree BIT-FOR-BIT. If they DISAGREE, that disagreement is the finding -- a rounding difference hiding in plain sight, not a licence to swap. Specific hazard: the banked backend observation is `addsd` (scalar DOUBLE). If OP_FADD lowers through f64, an f32 bit pattern held in an i64 would be double-rounded or reinterpreted outright. This probe is built to catch both. Reports agreement over every IEEE class -- signed zeros, both infinities, NaN, min/max subnormal, min/max normal, 1-ulp neighbours, rounding-sensitive pairs.