Lipschitz transform

[snowbldr]

Fix Transform3D Lipschitz under-correction for non-rigid matrices

Fixes one of the bugs in #85.

The bug

Transform3D evaluates by applying M⁻¹ to the query point and
forwarding to the inner SDF. The inner SDF returns a distance in the
untransformed space; if M is non-orthonormal (any axis scaling),
that distance is stretched by the largest singular value of M⁻¹:

|sdf_outer(p) − sdf_inner(M⁻¹·p)| ≤ σ_max(M⁻¹) · |p − q|

so Evaluate overstates true 3D distance by up to σ_max(M⁻¹). The
octree marching-cubes renderer's |sdf(center)| ≥ half-diagonal
pruning then skips cubes that contain surface, producing holes.

Pure rotation+translation has σ_max = 1 and the bug doesn't fire
there; it only matters once you compose with Scale3d or any
non-uniform scaling.

The fix

TransformSDF3 grows invStretch float64, set at construction:

sigma2 := m44LinearSigmaMax2(&s.inverse)
s.invStretch = 1
if sigma2 > 1 {
    s.invStretch = 1 / math.Sqrt(sigma2)
}

Evaluate multiplies its result by invStretch so the SDF stays a
valid Lipschitz-1 distance estimator. m44LinearSigmaMax2 computes
σ_max² of the 3×3 linear block via the closed-form symmetric-matrix
eigenvalue formula (Smith 1961) — no iterative SVD on the construction
path.

Diagonal matrices (which pure scaling produces) hit the p1 == 0
short-circuit returning max(a00, a11, a22). Pure rotation gives
σ_max² = 1 so invStretch = 1 (no behavior change).

Tests

render/transform_test.go:

• Test_Transform3D_Watertight — non-uniform scales {2,2,2},
  {3,1,1}, {1,1,3}, {2,3,4}, {5,1,5} on a unit sphere, octree
  at 80 cells, asserts zero boundary edges.
• Test_Transform3D_RigidPreservesDistance — pins that a rotated
  sphere's SDF at distance 1 equals 1 to ≤ 1e-9, so a future tightening
  of the σ_max calc can't accidentally apply a < 1 factor to rigid
  transforms (which would be safe but slow).

Architecture-specific note

Same family of bug as the high-taper screw rendering issue from #84 —
non-1-Lipschitz SDF that the octree's isEmpty pruning rule wrongly
trusts. Borderline configurations may render holes on x86_64 (FMA /
FTZ rounding differences) but not on Apple Silicon. The conservative
invStretch constant is tight enough to absorb 1-ulp wobble either way.