`monitor` mode emits no startup banner (version, config path, destination count) — long-running logs are hard to debug

[dolph]

Operability problem

connectivity monitor is intended to run as a daemon for days/weeks (per the help text in help.go:62-67). When an SRE tails the logs days into a run and tries to figure out what's actually going on, they see:

2026/05/16 03:14:22 Loading config from /etc/connectivity.yml
2026/05/16 03:14:22 Parsed the following destinations:
2026/05/16 03:14:22 [host-a][10.0.0.5] api: https://api.example.com/health
... (one line per destination at startup, then forever after just per-check messages)
...
2026/05/19 19:55:01 [host-a][10.0.0.5] api: Connected

There is no:

• Version line in the logs. connectivity version exists (help.go:15-27) but nothing in the monitor startup path calls PrintVersion. The operator looking at logs from a process that has been running for 5 days has no way to tell whether it's the build that was deployed last week or the older one from the rolling deploy.
• Effective configuration summary: which config file was loaded, what statsd endpoint is configured, what protocol — useful at startup to confirm the binary picked up the right config.
• Destination summary: total count, scheme breakdown.
• PID / start time line: helpful for correlating with a crash/restart.

Combined with the lack of any log rotation or self-rotation (Go's default log writes to stderr forever), this means an operator looking at a multi-day log file has no anchor for "when did this process actually start" — they have to grep for the first "Monitoring connectivity..." line and trust it.

Concrete operator scenario

"We deployed v1.4.2 last Tuesday with a known fix for the timeout bug. The pager fired tonight. I look at the monitor logs and see only [host-a][10.0.0.5] api: Connected lines going back two weeks. Did the new version actually roll out on this host? Is it still v1.3 from the rollback? There's no banner. I have to SSH in and run connectivity version to find out — which tells me what's installed now, not what the running process was started with."

"Statsd has been silently broken since yesterday (see #11). I tail the monitor logs hoping to see something — but the startup didn't print 'sending stats to udp://10.0.1.1:8125' so I can't even confirm where it's trying to send."

Suggested fix

At monitor/wait/check startup, log one banner line per item:

connectivity v1.4.2 (commit abc1234, built 2026-05-10) starting on host-a pid=4321
config: /etc/connectivity.yml (5 destinations: 2 https, 1 tcp, 1 udp, 1 icmp)
statsd: udp://10.0.1.1:8125

Each piece of information is independently load-bearing for the on-call. Note that the build-time variables in help.go:7-13 (GitTag, GitCommit, etc.) are already wired up — monitor just doesn't print them.

Operability-related and distinct from #19 (self-observability metrics, which is what the tool emits about itself over its lifetime) and #21 (structured logs, which is about HOW logs are formatted). This is about the startup snapshot that anchors the rest of the log stream.