Publish head-tracking control state without a lock

[olilarkin]

Follow-up to #25, which it replaces.

#25 correctly identified that SetHeadRotation(), EnableHeadTracking() and EnableLimiter() raced with Process() — a torn four-float quaternion write is a real hazard. It closed the race by taking mutex_ in the setters.

The concern is which side of the lock the fix landed on. Process() holds that same mutex "for the entire processing duration" (obr_impl.cc), so the setters now share a lock with the audio thread. absl::Mutex does not implement priority inheritance, so a control thread preempted while holding mutex_ stalls rendering until the scheduler runs it again — and head rotation is written continuously from a sensor thread, so this is contended on every buffer rather than rarely. Trading a torn read for a possible unbounded wait on the audio thread seems like the wrong direction: a renderer should not have to wait on a lower-priority thread.

This PR publishes the three values instead of locking them:

• the two flags become std::atomic<bool>;
• the quaternion goes through a new AtomicWorldRotation — a seqlock storing four std::atomic<float>, so concurrent access is defined behaviour rather than a data race that happens to be benign in practice.

std::atomic<WorldRotation> would be simpler, but at 16 bytes it is not lock-free on the platforms obr targets, so the implementation would take a hidden lock on the audio thread — the very thing being avoided.

The seqlock read is deliberately bounded rather than spinning to convergence. A reader that retries until it wins is unbounded when the writer is preempted between its two counter updates, which on an audio thread is no better than the lock this replaces. Load() gives up after a few attempts and returns the caller's previous value, so the read is wait-free. Reusing a rotation for one buffer is inaudible; missing a deadline is not.

Process() now latches all three once at the top of the block. That is also more correct than reading them where they were read before: ProcessingGroup interpolates the rotation across the buffer, so a value that can change partway through is arguably already wrong.

mutex_ is unchanged and still guards audio_elements_ and processing_groups_ — containers being rebuilt, rather than values being handed over. Nothing that runs continuously during playback takes it now.

Testing

• atomic_rotation_test (new): round trip, the concurrent no-tearing property, and the bounded fallback under a continuous write storm.
• ObrImplTest.TestConcurrentHeadRotationDuringProcessing (new): renders while a second thread sweeps head rotation and toggles both flags.
• Both are clean under ThreadSanitizer.
• The existing 65 renderer and processing-group tests pass unchanged.

No public API change.

Noticed while measuring, reported separately

Running Process() inside a [[clang::nonblocking]] region under RealtimeSanitizer shows 4 malloc / 4 free per render call, from the per-block AudioBuffer group_output and from PeakLimiter. That is independent of this change and of any locking — it happens single-threaded with head tracking disabled — so it is filed on its own rather than bundled here.

[trsonic]

Thanks @olilarkin for the PR submission. Before we proceed with the review, could you please sign the Contributor License Agreement, as explained in CONTRIBUTING.md. Let us know if you have any issues.