Add a static-delay measurement scenario

[balloob]

This test scenario was identified by a cross-SDK conformance audit comparing every Sendspin client/server implementation. See the audit docs on branch claude/stream-sync-correction-sdks-AWoNC.

What it tests

Server sends audio that should align at time T; client is configured
with static_delay_ms = 100; the harness measures actual emission
time and asserts it is T − 100 ms within tolerance.

Why we need it

This scenario catches two distinct bugs the audit found:

1. Parse-but-ignore — sendspin-rs and SendspinKit parse
   static_delay_ms from the protocol but never apply it in the
   playback path. The server pre-compensates for the delay, the
   client ignores it, alignment is off by exactly the delay amount.
   (Highest-severity bug in the audit.)
2. Forgot-to-persist — seven SDKs don't persist the value across
   restarts, despite the spec mandating it. The scenario can be run
   in a "configure, restart client, replay" variant to catch this.

Implementation sketch

• Existing audio-hash machinery, but with a known non-zero
  static_delay_ms.
• Harness compares emission timeline against a reference computed as
  expected_play_time − static_delay_ms.
• Tolerance derived from the spec's drift thresholds (well under
  5 ms — the static delay is hundreds of ms).

---

Source: docs/static-delay.md §recommendations