Fix 3D rotation composition with quaternions

[fly1d]

Fixes #1165.

Summary

• Store a normalized quaternion inside Rotation while keeping the public x, y, and z accessors and serialized shape.
• Compose Rotation values with the Hamilton product instead of adding Euler components.
• Apply Resource.rotate() increments in the parent-coordinate frame while preserving the existing Rotation instance and [0, 360) component normalization.
• Cover non-commuting rotations, parent-child composition, component assignment, gimbal-lock representations, and serialization round trips.

Why

Adding Euler components does not compose general 3D rotations. For example, applying an x-axis increment after a 90-degree z rotation produces a different matrix when the angles are added. Quaternion multiplication preserves the requested order without introducing a matrix-to-Euler conversion into each composition.

Euler angles remain part of the public and serialized API. Equivalent Euler representations are therefore selected close to the previous component-wise values, with an explicit singular case at pitch = +/-90 degrees.

Verification

• .venv/bin/python -m pytest -q: 2983 passed, 36 skipped, 759 subtests passed
• BIN=.venv/bin/ make lint
• BIN=.venv/bin/ make format-check
• BIN=.venv/bin/ make typecheck: 808 source files checked
• 10,000 deterministic composition and serialization checks, including near-singular angles: maximum matrix errors 1.110e-15 and 2.753e-12

No hardware was connected or driven.

AI assistance: OpenAI Codex assisted with implementation and test validation.

[BioCam]

@fly1d nice fix - this is the right way to do it. A heads-up on how it interacts with #1248, which I just merged.

This makes Rotation.get_rotation_matrix about 17x faster (5.0 → 0.30 µs) but Rotation.__add__ about 24x slower (0.16 → 3.88 µs).
Before #1248 the slowdown outweighed the speed-up, because get_absolute_location called __add__ a quadratic number of times, so the whole thing got slower.
Those calls are gone now, so against current main it comes out roughly neutral: 3-4% slower on an unrotated deck, no measurable difference on rotated chains.

The small slowdown is .x/.y/.z becoming properties (27 → 49 ns per read) - get_absolute_location reads all three once per chain level to decide whether a matrix is needed at all.
Comparing the stored quaternion against the identity instead would claw it back.

[fly1d]

Thanks. I rebased onto current main and applied the suggested hot-path fix in 6330eb50: get_absolute_location now compares the stored quaternion directly with the identity quaternion. The 88 focused tests, Ruff, formatting, and mypy on the changed modules pass.