tidy-guard: why DialControl strips its own address, with a test

[dinstein]

Nightly tidy pass over internal/guard/netguard (2026-08-10 05:17 round).
The slice produced no refactor, and that is the result.

netguard.go holds two implementations of "get the bare host out of this":
canonicalHost, and the inline strip inside DialControl. On a sweep for
duplicated logic — the shape that has landed three commits already tonight —
they look like one function written twice.

I differential-tested them before merging. They are not equivalent, and the
difference runs the wrong way:

input	DialControl today	via canonicalHost
" 8.8.8.8:53 "	unparsable → blocked	public address → dialled

canonicalHost trims surrounding whitespace, so it parses inputs DialControl
refuses. Every other input tried reaches the same verdict through both — bare
and bracketed v6, v4-mapped, portless, empty, ":8080", malformed — so that
is the whole of the difference.

No such address can arrive: net.Dialer hands Control the resolved
host:port it built itself. But a fail-closed predicate at the SSRF boundary
is the wrong place to widen what is accepted on the strength of an argument
about what cannot happen — and "the two look identical" is precisely how that
widening would arrive. It is the reasoning gateway.fsSafe already writes
down for itself against proclog's rule, which is what stopped me merging that
pair two rounds ago.

• Pass C — a comment on DialControl saying why the two stay apart.
• " 8.8.8.8:53 " joins TestDialControl's block list, so the comment is
  enforced rather than asserted. Mutation-checked: rewriting
  DialControl to call canonicalHost fails that case and nothing else.

No behaviour change. Verification: make ci green.