Support IPv6 node URLs and filter wildcard redirect endpoints

[PDGGK]

Problem

parseNodeUrls splits each node URL on : and requires exactly two parts, so an IPv6 endpoint such as [::1]:6667 is rejected up front with "Invalid nodeUrl format", making the client unusable with IPv6 nodes. Separately, on the redirect path the client caches and connects to whatever endpoint the server advertises in a redirectNode, with no guard against a wildcard/listen-all address.

Fix

Following the same approach as apache/iotdb#18162:

• Parsing: parse the bracketed [ipv6]:port form by stripping the brackets and reading the port after them, keeping IPv4 and hostname parsing unchanged. A bare (unbracketed) IPv6 address with a port is ambiguous and rejected; the [ipv6]:port form must be used.
• Wildcard filtering: after an insert, the server's redirectNode is stored in Session.lastRedirectEndpoint and later cached and connected to by the pool via getAndClearLastRedirect(). That consumption point now ignores a redirect whose address is a wildcard/listen-all address (0.0.0.0, ::), which is not a connectable remote endpoint — the current endpoint is kept.

Tests

• parseNodeUrls: bracketed IPv6 ([::1]:6667, [2001:db8::1]:6668) and malformed inputs (bare IPv6, unbalanced bracket, missing colon, empty port).
• isWildcardAddress, and Session.getAndClearLastRedirect on the real path: a wildcard redirect endpoint is dropped, a normal one passes through.
• Parsing is unit-tested including the [::1] loopback address; live IPv6-loopback connection tests (as in #18162) would need an IPv6-capable CI/test server, which I'm happy to add as a follow-up if the client CI supports it.

Existing tests and tsc pass. Follows the dev@ "[DISCUSS] Improve IPv6 endpoint support" thread; one focused PR per client as @HTHou suggested.

[HTHou]

One endpoint-parsing issue to address.

[PDGGK]

Thanks @HTHou — you're right, parseInt accepting a numeric prefix let malformed endpoints slip through. Fixed: the port must now be an all-digits string (validated with /^\d+$/) before conversion, so [::1]:6667junk and [::1]:6667:9999 — and the hostname/IPv4 equivalents — are rejected with the Invalid nodeUrl format error rather than parsed as 6667. Added regression tests covering all four cases.