#3276 classifyConnectionError mislabels non-auth connection failures as auth failures

classifyConnectionError in src/cli/remote_run.ts labels a WebSocket connect failure as an auth failure in one case. This happens whenever it can't parse the original error as an HTTP status or a TLS error, as long as a follow-up /health probe succeeds:

if (await probeServerHealth(wsUrl)) {
  return `Authentication failed — run: swamp auth server-login --server ${wsUrl}`;
}

This mislabels any other transient connection failure as an auth problem. Examples: a dropped connection, a brief accept-queue stall, a timeout-ish early close. The original error message never reaches the caller, logs, or telemetry. The CLI drops it entirely.

We hit this on a loopback pattern. A step running inside swamp serve calls swamp workflow run ... --server <same-serve-url> back into itself (similar shape to #2879). About 45% of these loopback calls fail with the auth message over a 7-day sample. But the serve's own logs show zero actual token rejections in the same window, only successes. So real auth is not the problem. Some other connection failure is happening and getting relabeled.

Suggested fix: when the health probe succeeds, surface the original err.message instead of overwriting it with the auth-failure guess. At minimum, include both. That way a caller or a log can tell the difference between two cases. One: the server is reachable but authentication failed (believable). Two: the server is reachable, but something else failed (what's actually happening here).

Happy to share the Honeycomb data or more repro detail if useful. We worked around it harness-side with a bounded retry, rather than trusting the literal message. The message itself still seems worth fixing for anyone else hitting a similar loopback or transient-connection pattern.

Automoved by swampadmin from https://github.com/swamp-club/swamp/issues/3006