fix: Keep a numeric host:port address out of the unparseable branch

[keelerm84]

Summary

Backport of the v9 fix in #879, for a regression that shipped in 8.22.0.

url.Parse rejects 127.0.0.1:8500 and [::1]:8500 with first path segment in URL cannot contain colon: a digit or [ cannot begin a scheme, and the first path segment cannot contain a colon. RedactURL treated any parse failure as "could be hiding a credential, replace it whole", so the whole address became xxxxx.

Consul's default address is exactly that shape, so a default Consul deployment reports

"dbServer": "xxxxx"

in the unauthenticated status resource, and logs the same in its startup line. Redis and DynamoDB addresses given as IP literals are affected the same way.

Only a letter-starting host (consul.example.com:8500, localhost:8500) parses -- as a scheme plus an opaque body -- which is why the existing cases could not cover this.

No credential is exposed; the failure is in the other direction. An operator loses the diagnostic value of the field, and a support case reading xxxxx cannot tell a redacted credential from a destroyed address. It is a regression rather than long-standing behavior: before #846, RedactURL returned the input unchanged when parsing failed.

Fix

A value url.Parse rejects is replaced whole only when it contains @, ? or #. Those introduce the only components this function redacts: userinfo, a query, and a fragment. A value containing none of them is a scheme, host, port and path, all of which the function preserves when they do parse, so preserving them here is the same decision rather than a weaker one.

redis://user:pass@127.0.0.1:not-a-port is still replaced whole, and so are unparseable values carrying a query or a fragment.

Tests

internal/util/util_test.go gains 127.0.0.1:8500, 10.0.0.5:6379, [::1]:8500 and 192.168.1.1, plus three cases proving an unparseable value carrying @, ? or # is still replaced whole. Each of the four new address cases returns xxxxx on the shipped code, so they fail without this change.

The redactUnparseable helper is byte-identical to the one on v9.

Reported by Cursor Bugbot on #879. Its account of the mechanism described url.URL.String inserting a ./ prefix, which is what happens to a relative path containing a colon; this input never reaches String, because Parse refuses it first. The conclusion was right either way.

---

Note

Overview
Fixes a 8.22.0 regression where RedactURL replaced unparseable strings entirely with xxxxx, so default Consul-style addresses like 127.0.0.1:8500 and [::1]:8500 disappeared from status and logs even though they contain no credentials.

On url.Parse failure, redaction now goes through redactUnparseable: values with @, ?, or # are still fully replaced (possible userinfo, query, or fragment); values without those characters are returned unchanged, matching the “preserve host/port/path” behavior used when parsing succeeds. Parsed-URL redaction is unchanged.

Tests cover IP literal host:port, bare IPs, and unparseable strings that still must be fully redacted.

^{Reviewed by Cursor Bugbot for commit 0b2bd19. Bugbot is set up for automated code reviews on this repo. Configure here.}