Latency lab: add the ASIO-lane scenario (--latency-lab asio)

Answers Ed's "and adjusting ASIO latency also happens quickly now?" with a measurement rather
than an assertion, and without needing an ASIO device: wires the engine as BothIndependent with
only the ASIO lane active, confirms the stream lands on AsioLane, and drives the raise/lower
through the ASIO slider's own route.

Measured: 54ms -> 289ms within 10s, holds at the 330ms target, lower back to 30ms within 3s —
the same fast approach as the single slider, as expected (one hard-setter path feeding whichever
lane the moved slider owns). No product change; harness only. The shipped v5.9 build is untouched.

Also made the harness faithful to the 5.9 arming change (NoteFramesQueued against the session's
own route target, not the engine-wide one) so the ASIO case arms the way the app does.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

lab-asio.txt

@@ -0,0 +1,18 @@
+RemSound latency lab - measuring depth-target convergence with the shipped playout code.
+Raise under test: 30ms -> 330ms. Expected growth at full depth-bias: ~3ms/s.
+
+--- T4 ASIO lane (two-slider mode): ASIO slider drives an ASIO-lane stream ---
+  session route after arrival: AsioLane  (slider writes to: AsioLane)
+  settled at slider 30ms: buffered=54ms
+  t+10s buffered= 289ms
+  t+20s buffered= 308ms
+  t+30s buffered= 311ms
+  t+40s buffered= 303ms
+  t+50s buffered= 322ms
+  t+60s buffered= 299ms
+  RAISE via slider: 54ms -> 299ms in 60s = 4.08ms/s  GROWS (slider works)
+  LOWER via slider: back to 30ms -> buffered=30ms after 3s
+
+
+=== SUMMARY ===
+  T4 ASIO lane (two-slider mode): ASIO slider drives an ASIO-lane stream: raise 4.08ms/s [GROWS (slider works)], lower -> 20ms