fix: restore original services on partial deployment failure

QUALIFICATION.md

@@ -11,6 +11,8 @@ Target: Unraid `192.168.86.2`, public UI `https://192.168.86.2:9178`.
 - User-facing test login username: `john-doe`. Initial passwords are generated,
   not committed or printed; obtain them from the protected deployment credential
   record or use administrator password reset in the website.
+- Final voice image: `sha256:ea86ac10377c553f32a70d24f46dea1413c949673ed1b9850a4aabbe8574e8d8`;
+  verified `healthy`. Final control HTTP health returned `{"status":"ok"}`.
 - No push performed. The existing dirty NAS checkout was not overwritten; clean
   build source was staged separately. Hope Music and unrelated services untouched.
 
@@ -47,6 +49,10 @@ also passes `model_options.reasoning.enabled: false` and forwards content only.
 - Administrator deletion immediately invalidated session/bootstrap; lifecycle
   removed the account and its named container. Private data retained deliberately.
 - Logout invalidated the token; room grant revocation also covered offline.
+- Actual Azure out-of-band wait-notice and final answer audio received over
+  WebRTC on two independent tracks (measured nonzero peak levels 0.904 / 0.786).
+  Probe used authenticated LiveKit text input with agent voice output and muted
+  synthetic microphone; this verifies synthesis/transport, not physical STT.
 - Actual speech worker registered and final container health passed. Health now
   checks HTTPS, LiveKit, control and PID-bound worker endpoint, not just web shell.
 
@@ -108,6 +114,8 @@ contains no usable key. Keep API origins synchronized for new DNS names.
 Real physical microphone recognition, perceived speech quality, barge-in and
 an installed iPhone against the NAS have **not** been claimed. Self-signed SDK WSS
 trust may require installing a trusted private CA on the iPhone; native HTTP pinning
-is not a guarantee the SDK socket trusts that certificate. No trust-all/plaintext
+is not a guarantee the SDK socket trusts that certificate. The deployed public
+leaf certificate SHA256 was compared with the native HTTP pin and matched exactly
+(`07907abde3bb9c685265909927627d9ea4705d7e7b27056eefe06e10b192af46`). No trust-all/plaintext
 fallback was added. Browser automation's certificate exception is a test setting,
 not production TLS policy. See iOS project handoff for test artifacts.