Surface safe stdio startup diagnostics instead of only server disconnected #302

Problem

When a configured stdio server exits during startup, PMCP exposes only Server brightdata disconnected through health/provisioning results. The caller cannot distinguish a launcher failure from authentication, transport, or downstream initialization problems, and receives no actionable diagnostic location.

Observed with PMCP CLI 2.7.3 on Linux on 2026-09-26. The running gateway's exact package version was not independently queried.

Observed behavior

1. A configured BrightData server used a local Python launcher.
2. gateway.provision(server_name="brightdata") reported that the configured server could not start, with an empty missing_env_vars list and unknown authentication state.
3. gateway.health reported status error, zero tools, and Server brightdata disconnected; subsequent health reported auth_state: none, with no next step.
4. pmcp logs --server brightdata --tail 100 found no CLI-visible log file in this deployment. This does not establish that no service journal exists.
5. Inspection found that the launcher required exactly one node-v*/bin directory, but the managed release intentionally contains two Node majors. The launcher catches the exception, emits a generic startup diagnostic to stderr and returns exit code 1. Credential lookup independently succeeded; no credential contents are included here.

The launcher's stderr message was:

Bright Data launch failed: check managed Node and the Regenesis 1Password service account credential source.

The specific Node ambiguity was found by inspecting the launcher; PMCP cannot recover an exception that the launcher itself suppresses. The PMCP improvement is to expose available failure evidence and its limitations, not infer that hidden exception.

Confirmed local resolution

The launcher was changed to use the managed release's existing bin/npx selector instead of requiring a single installed Node directory. gateway.connect_server then moved BrightData from error to online, its search tools became discoverable, and a real search returned results. The first search exceeded the default 30-second tool timeout; a second with a 60-second budget succeeded. That execution timeout is separate from the startup diagnostics problem.

No PMCP change was needed to repair this particular launcher.

Expected behavior / acceptance criteria

• A stdio startup failure reports the startup phase and subprocess exit status when known.
• Preserve a bounded, sanitized stderr diagnostic or a safe reference explaining where to retrieve it. Never expose raw environment values, credential payloads, tokens, or authorization headers.
• Distinguish missing information from confirmed authentication failure or absence of authentication requirements.
• Surface consistent diagnostic context in connect/provision/health responses, with a useful next step.
• Add a regression test with a synthetic server that writes a safe diagnostic to stderr and exits with status 1 before completing initialization; assert the diagnostic survives the failure path.
• Include redaction and truncation tests, and a failure with no stderr.

Related but not an exact duplicate: #232 concerns downstream protocol handling and stderr decoding; #287 concerns handshake failure task cleanup.