Dual-stack public IP discovery for cluster address reporting

Problem

Clusters on dual-stack VPS hosts (e.g. Hetzner Cloud) report incomplete or unusable API addresses to miren.cloud:

1. 0.0.0.0:8443 gets reported and stored — when the server binds to 0.0.0.0, this address is included in the status report. Cloud stores it as-is. It's meaningless as a connectable address.
2. Only one address family is discovered — IP discovery calls ifconfig.co which returns whichever address family the OS uses for outbound (IPv6 on Hetzner). Netcheck also runs single-stack. So only one set of public addresses is reported, even when both IPv4 and IPv6 are available and assigned to the interface.

The result: miren cluster add shows 0.0.0.0:8443 as the primary address, and may only have one address family available. Connection attempts fail or are unreliable depending on the client's connectivity.

Fix

Runtime:

• Drop ifconfig.co dependency — local interface enumeration already provides all IPs for cert SANs, and netcheck is the authoritative source for public addresses
• Make netcheck dual-stack — run concurrent calls forced over tcp4 and tcp6 to discover public addresses on both address families

Cloud:

• Allow zero-port netcheck requests (enables lightweight IP-only discovery)
• Filter 0.0.0.0 from stored API addresses (defense in depth)

Follow-ups

• miren cluster list --available to query cloud-known clusters with full address details (including --format=json support)
• Consider whether explicitly configured IPs (via server.toml additional_ips) should survive the netcheck filter

Workaround

miren cluster add --address <ip>:8443

Bypasses cloud address discovery entirely by connecting directly.