Integrate reviewed topology-free demo readiness diagnostics

Change-source: pulse-maintainer

docs/release-control/v6/internal/HIGH_RISK_RELEASE_VERIFICATION_MATRIX.md

@@ -1029,6 +1029,14 @@ Companion drill:
     complete missing-package list is a failed boundary check, not qualification.
   `cd scripts/release_control && python3 -m unittest resolve_release_promotion_test release_promotion_policy_test`
   `go test ./scripts/installtests -run 'Test(Demo|DeployDemo|UpdateDemo|Release)' -count=1`
+  - `TestDemoReachabilityStopsBeforeUnreadyOrFailedTailnetProbes` executes
+    synthetic local daemon/probe commands: failed setup diagnostics never
+    contact the host, non-running/malformed status cannot pass readiness,
+    failed tailnet ping cannot fall back to TCP, and workflow output excludes
+    private topology, including stdout/stderr from both probes on success or
+    failure. Running-state success still requires both ping and SSH
+    transport, with bounded TCP failures retained. This is offline helper
+    correctness, not live OAuth access or installed demo acceptance.
 - Manual scenario:
   - Compare the exact selected release notes with the install-metadata verdict.
     Authored grouped notes must retain version identity, unsigned-Windows and

docs/release-control/v6/internal/subsystems/deployment-installability.md

@@ -4114,8 +4114,23 @@ hostnames or Tailscale IPs, rather than silently depending on public SSH
 reachability from GitHub-hosted runners. The workflow must use the current
 pinned Tailscale GitHub Action, its target `ping` readiness gate, and the shared
 `.github/scripts/check-demo-reachability.sh` TCP/22 diagnostic before SSH key
-capture. A successful tailnet join alone is not connectivity proof. After that
-network preflight, shared SSH
+capture. A successful tailnet join alone is not connectivity proof.
+
+The shared helper's `diagnose` mode is local-only after a failed setup action:
+it must not ping the peer or attempt direct TCP as a fallback. Its `check` mode
+requires recognised local `Running` state before any probe, then a successful
+tailnet ping before TCP/22. Missing, malformed or non-running daemon state is
+an incomplete setup result, not proof that the demo is down. Failed ping is
+retained without another diagnostic ping or TCP attempt. Status diagnostics
+report only allowlisted backend states and peer-presence/online/active booleans;
+they never print tailnet addresses, DNS names, tags, relay locations, raw JSON
+or local CLI errors. Tailnet and TCP probe stdout/stderr are also suppressed
+on both success and failure; their exits and bounded, topology-free verdicts
+remain visible. Diagnostic success cannot establish connectivity or
+installed acceptance, and neither mode changes credentials or authorises
+replaying a provider refusal.
+
+After that network preflight, shared SSH
 setup must wait for configured demo hostnames to resolve, accept configured IP
 literals without a DNS precheck, and then capture host keys with bounded
 short retries before any installer or binary copy runs; a long `ssh-keyscan`