Audio verify: distinguish a failed process-loopback from no-correlation

verify_stream_format ignored ProcessLoopbackCapture::start()'s bool. A failed
loopback activation then produced an empty ground-truth signal, so the result was
ok=false -- indistinguishable from "captured fine but the two paths didn't
correlate" -- after burning the whole measurement window capturing only the hook
side for nothing.

Now it checks start(): on failure it restores the ring tap, emits a clear
OutputDebugString diagnostic, and returns immediately (ok=false) instead of
wasting the window. The caller still falls back to the measured guess, but the
cause is now visible.

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

README.md

@@ -114,8 +114,6 @@ From an in-depth review pass. Each item is fixed test-first (a failing test, the
 as its own commit; "verify" items are confirmed real before any change, and dropped if not.
 
 Robustness (verify, then fix if real):
-- **Swallowed audio loopback `start()` failures** — surface a process-loopback activation failure
-  distinctly from "no correlation" in the verifier + loopback.
 - **Permissive injector bitness gate** — `IsWow64Process2` failure is treated as 64-bit; fall back to
   `IsWow64Process` instead of mis-injecting.
 - **Ignored HRESULT/BOOL returns** — `CreateShaderResourceView`, `GetClientRect`/`ClientToScreen`,