envd/controller: don't parse replica internal-http addrs as SocketAddr

[def-]

Follow-up to #35169

Seems to cause panics in Cloudtest, which uses hostnames instead of IPs:

2026-02-23T14:20:49.944020Z  thread 'coordinator' panicked at /var/lib/buildkite-agent/builds/buildkite-l-builders-aarch64-static-9f59e6a-i-06dcfc2ae8a94894e-1/materialize/test/src/controller/src/clusters.rs:447:54:
valid socket address: AddrParseError { kind: Inet }
   6: core::panicking::panic_fmt
   7: core::result::unwrap_failed
   8: <core::iter::adapters::map::Map<core::slice::iter::Iter<alloc::string::String>, <mz_controller::Controller>::create_replica::{closure#0}> as core::iter::traits::iterator::Iterator>::fold::<(), core::iter::traits::iterator::Iterator::for_each::call<mz_ore::netio::socket::SocketAddr, <alloc::vec::Vec<mz_ore::netio::socket::SocketAddr>>::extend_trusted<core::iter::adapters::map::Map<core::slice::iter::Iter<alloc::string::String>, <mz_controller::Controller>::create_replica::{closure#0}>>::{closure#0}>::{closure#0}>
   9: <alloc::vec::Vec<mz_ore::netio::socket::SocketAddr> as alloc::vec::spec_from_iter::SpecFromIter<mz_ore::netio::socket::SocketAddr, core::iter::adapters::map::Map<core::slice::iter::Iter<alloc::string::String>, <mz_controller::Controller>::create_replica::{closure#0}>>>::from_iter
  10: <mz_controller::Controller>::create_replica
  11: <mz_adapter::coord::Coordinator>::bootstrap::{closure#0}::{closure#0}
  12: <tracing::instrument::Instrumented<<mz_adapter::coord::Coordinator>::bootstrap::{closure#0}::{closure#0}> as core::future::future::Future>::poll
  13: <tracing::instrument::Instrumented<mz_adapter::coord::serve::{closure#0}::{closure#4}::{closure#0}> as core::future::future::Future>::poll
  14: <tokio::runtime::park::CachedParkThread>::block_on::<tracing::instrument::Instrumented<mz_adapter::coord::serve::{closure#0}::{closure#4}::{closure#0}>>
  15: tokio::runtime::context::runtime::enter_runtime::<<tokio::runtime::handle::Handle>::block_on_inner<mz_adapter::coord::serve::{closure#0}::{closure#4}::{closure#0}>::{closure#0}, core::result::Result<(), mz_adapter::error::AdapterError>>
  16: <tokio::runtime::handle::Handle>::block_on::<mz_adapter::coord::serve::{closure#0}::{closure#4}::{closure#0}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Test run: https://buildkite.com/materialize/nightly/builds/15317

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

[teskje]

I'd like to understand why the original failed (and why this change fixes it), but I can look into that async. Fine to merge to fix the tests!

[def-]

My understanding is that Cloudtest uses hostnames instead of ip addresses directly.

[teskje]

Ah, I missed that SocketAddr::from_str doesn't do a DNS lookup. Your fix makes sense then, thanks!