A useful capability — being able to exercise the multihost code paths in a single container without docker/k8s removes a real friction point for development. The structure (one supervisor task per member, watch channel for cancellation, exit code 55 transparently re-spawning) mirrors the existing pipeline_run.sh supervision loop closely enough that the mental model carries over, and the doc comments on the loopback layout (third octet = ordinal, 255 for coordinator, fixed non-zero second octet so HTTP servers never collide with api-server/compiler/runner on 127.0.0.1) are the kind of thing I wish more code came with. Tests for IP layout are exactly the right thing to lock down.

A few non-blocking observations, defer to @blp on whether any are worth acting on:

1. macOS reality vs. the doc comment. The MULTIHOST_LOOPBACK_OCTET doc says the addresses can be pre-aliased once on macOS, but nothing in this PR actually does that aliasing — a developer on macOS will hit an opaque bind: Can't assign requested address from the host process and have to debug their way to ifconfig lo0 alias 127.100.0.1 etc. Either a CLI helper / Makefile target to set the aliases, or a startup probe that catches the bind error and prints a clear "run sudo ifconfig lo0 alias …" hint, would save someone an afternoon. Even just a README pointer would help.

2. Unbounded restart loop on exit code 55. supervise_member re-spawns immediately with no backoff or attempt counter. If a coordinator and a host get into a coordinated-restart livelock (config mismatch, port still in TIME_WAIT, whatever), this hot-spins and floods logs. A small sleep(Duration::from_millis(250)) before continue, plus maybe a "more than N restarts in M seconds → record fatal" guard, would match what real supervisors (systemd, k8s) do and matches the spirit of Power-of-Ten rule 2 (bounded loops). Cheap insurance.

3. Drop signals cancel but does not await supervisors. That matches the single-process path's start_kill shape, so it is consistent, but worth noting that if the tokio runtime is being torn down at the same moment, the detached supervisors may not get to kill their children and the host-* / coordinator processes can outlive the manager. Probably OK for local-dev, but if a developer ctrl-Cs the manager mid-run they may end up with orphans listening on those 127.100.x.1 ports — which then break the next run. A quick pgrep -f feldera-coordinator note in the docs, or having provision_multihost start by killing anything still bound to its target addresses, would be friendlier.

4. Same 28080 for coordinator and host HTTP ports. The constants MULTIHOST_PIPELINE_HTTP_PORT and MULTIHOST_COORDINATOR_PORT are both 28080, which is fine because IPs differ, but the "shared across hosts because their IPs differ" wording on the host constant invites the reader to think the coordinator is on a different port. Either collapse them into one MULTIHOST_HTTP_PORT constant or add a one-line comment on the coordinator one explicitly noting the deliberate equality.

5. Clamp-then-check ordering. n_hosts = requested_hosts.clamp(1, workers) followed by if n_hosts > MAX_MULTIHOST_HOSTS is technically correct (since workers >= 1 and the clamp can only shrink), but the more obvious shape is if requested_hosts > MAX_MULTIHOST_HOSTS { err } first, then the clamp. The current ordering makes the reader prove that clamp(_, workers) can't push above MAX_MULTIHOST_HOSTS, which it can't, but the assertion is implicit.

6. is_provisioned race. multihost.error() is checked, then a TCP connect; a member could fail fatally in between and we'd return Ongoing. Self-correcting on the next poll, so not a real bug — just calling it out.

Overall direction looks good to me. Marking COMMENT rather than APPROVE since @blp is the requested reviewer and the author explicitly invited his judgment on the direction.

This is a good idea, and thank you for doing it. I looked over most of the code, some in detail and some in a cursory way. Even if it does not work perfectly, it won't hurt the rest of the system.