fix(tests): %-by-zero NaN sign is platform libm — pin engine==oracle bit agreement, not a constant (CI)

Windows ucrt says 7ff8, Linux glibc fff8; both engines call the platform
libm so they agree per-platform (the cbrt situation again). fmod's NaN is
hardware-generated (0*inf under SSE) and stays fff8 everywhere — that
constant keeps its pin. Spec addendum updated.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: 2 people

docs/superpowers/specs/2026-07-26-wave3-builtin-pins.md

@@ -106,8 +106,12 @@ noted. Nothing here is inferred from documentation.
   INT x%0 → NULL (no trap); DOUBLE x%0.0 → **NaN 7ff8…** (a value, NOT
   NULL — the fleet's decision line over-generalized from the int probes;
   re-measured 2026-07-26, correction appended to pins-wave3/math_tail.json.
-  Note the NaN-sign contrast: %-by-zero is 7ff8, fmod-by-zero is fff8);
-  mod(−7.5,2.5) = **−0.0**.
+  NaN-sign addendum (CI-discovered): the %-by-zero NaN comes from LIBM
+  fmod and its sign is PLATFORM-dependent — 7ff8 on Windows ucrt, fff8 on
+  Linux glibc; both engines use the platform libm so they agree with the
+  oracle per-platform, and the pin is bit AGREEMENT, not a constant.
+  fmod-by-zero is hardware-generated (0·inf under SSE) and stays fff8
+  everywhere); mod(−7.5,2.5) = **−0.0**.
 - `fmod`/`fdiv` are the FLOOR-division pair, always DOUBLE: fdiv =
   floor(x/y) (±inf on zero divisor); fmod takes the **DIVISOR's** sign
   (fmod(−7.5,2.5) = +0.0 where mod gives −0.0) and is computed as

tests/test_duckdb_wave3_mathtail.py

@@ -204,9 +204,13 @@ def test_fdiv_fmod_double_edges():
 
 
 def test_computed_nan_bits_match_oracle():
-    # repr collapses every NaN to 'nan', so pin the BITS manually: fmod's
-    # computed NaN is fff8… (negative quiet NaN) while % by zero NULL-path
-    # NaN stays 7ff8… — in BOTH engines.
+    # repr collapses every NaN to 'nan', so pin the BITS manually. fmod's
+    # NaN comes from hardware arithmetic (0*inf under SSE) and is fff8…
+    # on every x86 platform. The %-by-zero NaN comes from LIBM fmod and
+    # its SIGN is platform-dependent (Windows ucrt 7ff8…, Linux glibc
+    # fff8… — CI-discovered, the cbrt situation again): both engines use
+    # the platform libm, so the pin is ENGINE == ORACLE bit agreement,
+    # not a constant.
     def bits(v: float) -> str:
         return format(struct.unpack("<Q", struct.pack("<d", v))[0], "016x")
 
@@ -218,14 +222,13 @@ def bits(v: float) -> str:
     )
     (got,) = fn.infer({"__THIS__": [row(x=7.5, y=0.0)]})
     assert bits(got.f) == "fff8000000000000"
-    assert bits(got.m) == "7ff8000000000000"
 
     con = duckdb.connect()
     con.execute("CREATE TABLE __THIS__ (x DOUBLE, y DOUBLE)")
     con.execute("INSERT INTO __THIS__ VALUES (7.5, 0.0)")
     f, m = con.execute("SELECT fmod(x, y), x % y FROM __THIS__").fetchone()
     assert bits(f) == "fff8000000000000"
-    assert bits(m) == "7ff8000000000000"
+    assert bits(got.m) == bits(m), f"{bits(got.m)} vs oracle {bits(m)}"
 
 
 # ----------------------------------------------------------- nextafter: