Add a drift-injection scenario to verify stream sync correction

[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 deliberately skews timestamps by a known amount partway
through a stream; the harness asserts the client's recovered audio
still hashes to the expected output within a tolerance derived from
the spec's soft/hard correction thresholds.

This is the conformance hook that turns the recommended thresholds
(100 µs soft / 5 ms hard / 500 ms reanchor, see
spec issue: stream sync correction) into something we can
actually measure.

Why we need it

Today the harness exercises happy-path streaming. The two SDKs that
implement spec rule #1 correctly (sendspin-cpp, sendspin-cli) and
the four that diverge in different directions (sendspin-dotnet
adds a resampler, sendspin-js adds rate adjust, sendspin-go/
sendspin-jvm/aiosendspin do no active correction) are
indistinguishable from a conformance perspective because nothing
forces them off their happy path.

Implementation sketch

• Server adapter mode that emits chunks with timestamps offset by a
  step function: nominal for 5 s, then +20 ms for 5 s, then nominal.
• Client adapter records emitted audio; harness compares hash against
  fixture allowing tolerance proportional to expected correction error.

---

Source: docs/stream-sync-correction.md §recommendations