Refactor `gateways.toml` to separate hostname and port, fall back to default port if omitted

[sanity]

Description:
We currently store a gateway’s hostname and port in one field (hostname = "vega.locut.us:31337"). This is confusing because it forces the port to be part of the “hostname.” Worse, if a port is omitted, the code sometimes falls back to a random port rather than 31337, which breaks connectivity.

Goals:

1. Separate Host and Port Fields
   • It should be clearer to specify a gateway’s address with two fields, e.g.

     [[gateways]]
     public_key = "keys/public.vega.gw.pem"
     address = { host = "vega.locut.us", port = 31337 }
     

     This means no more embedding the port in a single hostname string.
2. Maintain Backward Compatibility
   • Existing configs that do something like hostname = "vega.locut.us:31337" should still parse correctly, so we don’t break existing deployments.
   • If no port is specified, we should default to 31337 rather than picking a random port.
3. Enum Handling
   • Our Rust code uses an enum Address { Hostname(String), HostAddress(SocketAddr) }. We can either:
     • Switch to a small struct with { host, port }, plus a separate field for IP addresses; or
     • Extend the enum to parse missing ports as default 31337 and treat them correctly.
4. Clarify Behavior
   • For a gateway, a missing port is invalid or defaults to 31337—no more random picking.
   • Possibly rename the existing “hostname” variant to something more accurate (“host” or “host:port”).

Discussion Points:

• How best to parse older gateway.toml files without forcing everyone to rewrite them.
• Whether we require a port for gateway usage or just default to 31337 for everything.
• Any side effects with local vs. remote addresses.

Proposed Next Steps:

1. Implement a safe fallback for missing ports (31337 instead of random).
2. Allow the new format (address = { host = "vega.locut.us", port = 31337 }) while still parsing the old format.
3. (Optional) Migrate code away from the Hostname(String) enum variant to something more robust.

This change will remove confusion around “hostname:port” vs. “port is random,” while letting older configs remain valid.