don't hardcode service port numbers when available from SRV records

in https://github.com/oxidecomputer/omicron/pull/6320 i found a few places where we construct a SocketAddr (or SocketAddrV6) from an IP that we retrieve via a SRV record, but a hardcoded port. there's also a port in the SRV record; either it's authoritative and we should use it, or we've tied two services together by address, with one part implicit in source.

in these cases, we might either be able to add SRV records or maybe even use existing records:

• wicket assumes that the techport proxy can be done on the same IP as Nexus' API, just a different port. if there isn't a SRV record here, might be able to add one?
• we assume the CRDB admin service listens on the same IP as CRDB itself, but we could have a distinct SRV to point to the admin service directly.
• we look up addresses for MGS here via ServiceName::Dendrite, but there's a ServiceName::ManagementGatewayService we could use instead. this might just be a typo, with things otherwise set up for MGS.

Start by reading the SocketAddr construction in wicketd/src/nexus_proxy.rs, nexus/reconfigurator/execution/src/omicron_zones.rs, and sled-agent/src/bootstrap/early_networking.rs. Trace the SRV lookups and the ServiceName definitions, then determine which records or service names apply. Done means these connections no longer pair SRV-resolved IPs with unrelated hardcoded ports or service identities.