import { type DoctorCheckGroup } from "../types.js";
/**
 * Why the TLS anchor on this probe does not identify who answered, or `null`
 * when it does.
 *
 * ── THE SHAPE OF A REFUSAL PROVES NOTHING ON ITS OWN ─────────────────────────
 * The previous fix here demanded 401 + `application/json` + a string `error`,
 * and called that "the relay". Any intermediary can emit exactly those three
 * bytes-for-bytes; a shape is a thing anyone can copy, so requiring more of it
 * would not have helped either. The identification, if there is one, has to come
 * from something an intermediary cannot copy.
 *
 * There is exactly one such thing available to an unauthenticated probe, and we
 * already depend on it: the connection is `wss:`, and Node validated the
 * certificate chain against its OWN bundled Mozilla root store. A proxy, a
 * captive portal or a corporate gateway that wants to answer for the relay must
 * therefore hold a publicly trusted certificate for the relay's hostname — which
 * is a different and much larger claim than "it can return a JSON 401".
 *
 * That argument holds only while the bundled store really is the anchor, and a
 * handful of settings quietly move it — which is precisely how a TLS-inspecting
 * gateway gets installed in the first place: two environment variables here, and
 * every flag in `TRUST_STORE_FLAGS` below, which is the list that has to stay
 * complete for the `ok` to be earned. Each one is observable from here,
 * and when any of them is in force the probe cannot identify the responder at
 * all; it says so, in a `warn`, rather than reporting a captive portal as a
 * healthy WebSocket path.
 */
export declare function tlsAnchorCaveat(wsUrl: string): string | null;
export declare const connectivityChecks: DoctorCheckGroup;