Ports the subnormal-normalize step of the f64 decompose half from
ref/hare/math/floats.ha: issubnormalf64 (floats.ha:179) and normalizef64
(floats.ha:256, the f64-multiply-on-subnormal that yields (f64, i64)).
frexpf64 (floats.ha:278) is held back, not ported: its Hare-exact zero
guard `n == 0f64` miscompiles. A no-decimal `0f64` literal used as an f64
comparison operand is materialized into a GPR and never moved to XMM, so
the UCOMISD reads a stale operand and `n == 0f64` is wrong for every n.
Both stages emit this identically, so the byte-id gates are blind to it.
`0.0` compiles correctly but substituting it would be a workaround
(rule 7), so frexpf64 waits for the cgen fix. normalizef64/issubnormalf64
touch neither the broken literal form nor any tuple-field comparison, so
they are correct and land now.
Mirror Hare's single-expression `*(&n: *T)` structure (CLAUDE.md
rule 12) instead of a let-temp two-step that added a binding Hare
has no counterpart for. Document the load-bearing parens (rule 8):
ww's `:` cast binds tighter than unary `&`, so the bare Hare form
parses as `*(&(n: *T))`; `(&n): *T` is what reinterprets the address.
ref/hare/math/floats.ha:5,11. Byte-identical both stages; 952 6/6.
