Series C — -scan-resolvers subcommand

[Isusami]

Summary

Adds a -scan-resolvers subcommand that probes the configured resolver list outside the normal client startup path and writes surviving resolvers to stdout. Useful for sanity-checking resolvers, scripting, and as a foundation for future -doctor / re-discovery flows.

What changed

1. C1 — Extract ProbeResolverMTU + ScanOnce (refactor) — splits the inline probe path inside RunInitialMTUTests into a single-resolver primitive (ProbeResolverMTU, decoupled from *Client via an options struct) and a multi-resolver helper (ScanOnce). RunInitialMTUTests now drives ProbeResolverMTU through its existing worker pool so per-completion logging and counter ordering are unchanged.
2. C2 — -scan-resolvers flag + caller — new -scan-resolvers flag in cmd/client/main.go dispatches (after Bootstrap, before banner / runtime loop) to internal/client/scancmd.go, which loads the resolver list, calls ScanOnce, and writes results to stdout.
3. C3 — Output format + exit codes — output honors MTU_SERVERS_FILE_FORMAT if set (default {IP}), reusing the existing formatMTULogLine placeholder vocabulary so {IP}, {DOMAIN}, {UP_MTU}, {DOWN_MTU}, etc. all work. Exit codes: 0 = wrote at least one resolver, 2 = empty result (warn on stderr), 1 = setup / I/O failure.

How it works

• The single-resolver primitive ProbeResolverMTU(ctx, conn, opts) Result is the unit of work — one resolver, one probe outcome. It takes a ProbeResolverMTUOptions struct (rather than *Client) so it can be reused outside the normal client lifecycle. The seam is intentionally narrow: just the per-domain max upload payload, the upload/download probe callables, and an optional transport-opener for tests.
• The multi-resolver helper ScanOnce(ctx, opts) []Result iterates the candidate resolvers and aggregates per-resolver results in input order, with worker-pool fan-out clamped to [1, len(connections)]. ScanOnce is intentionally side-effect free — no balancer mutation, no logging, no rendering — so callers layer their own post-processing on top.
• The -scan-resolvers subcommand short-circuits before the normal client startup: it loads config + connections via the existing Bootstrap path, builds the scan options via Client.buildScanOnceOptions, calls ScanOnce, renders the surviving resolvers using MTU_SERVERS_FILE_FORMAT (default {IP}), prints them to stdout, and exits with the documented code.
• The existing RunInitialMTUTests path now calls ProbeResolverMTU indirectly through runConnectionMTUTest — no observable behavior change for normal client startup.

API layering

• ProbeResolverMTU (single-resolver primitive) is the one a future -doctor flow (D3) is expected to reuse — each resolver probed once at MIN_UPLOAD_MTU via a fixed-MTU UploadProbe/DownloadProbe instead of the binary-search variants used today.
• ScanOnce (multi-resolver helper) is what -scan-resolvers (this PR) and any future re-discovery trigger call.
• The two are kept distinct on purpose so future doctor / re-discovery work doesn't have to drag the wrong abstraction along.

Example usage

# Basic — print one IP per line (default {IP})
./client -config client_config.toml -scan-resolvers

# With a custom format from your config
# (client_config.toml: MTU_SERVERS_FILE_FORMAT = "{IP}")
./client -config client_config.toml -scan-resolvers > resolvers.txt

# Scripting on exit code
if ./client -config client_config.toml -scan-resolvers > resolvers.txt; then
    echo "Found at least one healthy resolver"
fi
# exit 0 = at least one resolver
# exit 2 = empty result (no resolver survived) — warning on stderr
# exit 1 = setup / I/O failure

Test plan

• go vet ./...
• go build ./...
• go test ./...
• ScanOnce matches an inline ProbeResolverMTU loop on a shared fixture across several worker counts.
• ProbeResolverMTU produces the expected per-connection result for accepted, upload-rejected, download-rejected, and transport-failure cases.
• -scan-resolvers writes the expected resolver lines to stdout with the default {IP} format.
• Custom MTU_SERVERS_FILE_FORMAT roundtrips through the output renderer (placeholders include the per-result {UP_MTU} / {DOWN_MTU} measurements).
• Blank MTU_SERVERS_FILE_FORMAT falls back to the raw resolver IP.
• Empty ScanOnce result and all-rejected paths return exit code 2 with a warning on stderr.
• Write-failure path returns exit code 1 with the underlying error surfaced on stderr.
• Nil-client guard on ScanResolvers returns exit code 1.