Add the wide world-position family, so a 128-bit consumer can actually use this

[rowan-claude]

Seven functions: fixLerpPositionWide, fixTransformWorldPointWide, fixInvTransformWorldPointWide, fixMakeWorldTransformWide, fixMulWorldTransformsWide, fixInvMulWorldTransformsWide, fixToRelativeTransformWide.

Why — not symmetry for its own sake

A consumer whose world positions are 128-bit cannot call the narrow forms at all; the parameter type is the thing that differs. box3d's ludicrous build hit exactly this — moving its AABB onto this library failed with assigning to 'fixPosWide' from incompatible type 'b3Pos', because the AABB is built from world positions and the position family had nowhere to land. The bounding volumes and the position family have to cross together, or neither can.

Deliberately not added

Second names for things already here. fixPosWideSub is the wide SubPos, fixPosWideOffset the wide OffsetPos, fixPosWideFromVec3/ToVec3 the wide ToPos/ToVec3. Four of the eleven a naive port would have written already existed.

The one that is not a mechanical widening

fixLerpPositionWide computes a + t*(b-a), not (1-t)*a + t*b. Widening the narrow form directly would multiply an absolute 128-bit coordinate and overflow. The reformulation multiplies only the difference, which is in local range.

That is one rounding instead of two, so it is deliberately not bit-identical to the narrow build. A consumer running both widths carries separate goldens, and no amount of care will make them agree — the wide answer is the more accurate one. Ported with its reasoning rather than re-derived.

Testing

Every function is called; a header-only function nothing references is invisible to a passing build.

The round-trip test is worth noting. My first assertion demanded exact recovery of the input and failed. A control measurement showed the narrow-only rotate/inv-rotate loses the same 2 ULPs and the wide route adds none — so the property worth pinning is that the 128-bit translation contributes nothing. Asserting equality with the input would have been asserting that fixed-point rotation is lossless, which is a different and false claim.

Also: a frame relative to itself is the identity translation; two frames a local distance apart at a 2^95 base recover that distance exactly (the premise of the design); lerp endpoints exact at any distance, midpoint exact, monotone along the segment.

Proven able to fail: swapping the lerp difference operands breaks four checks including monotonicity. Both frozen hashes unchanged.