delete unimplemented broadcast transport path [need discussion]

[TianyeGGBond]

Context

MilesModelUpdateService.sync_selected_workers was named/documented as a
two-path weight transport (cpu_serialize + NCCL broadcast) and exposed a
public broadcast_local_ranks kwarg. But any non-empty value immediately
raised NotImplementedError: the cache-owner sender-side NCCL path
(init_process_group + per-bucket dist.broadcast) was never wired — only
the receiver-side fan-out existed.

So the only path that ever runs is cpu_serialize. The broadcast kwarg,
subset validation, NCCL rank assignment, and world_size math are dead
code that makes the surface look like it offers something it doesn't.

Change

pipeline/miles_model_update_service.py:

• Remove the broadcast_local_ranks kwarg from sync_selected_workers,
  along with the subset validation and the NotImplementedError branch.
  Every target now goes over cpu_serialize.
• Drop the broadcast_set parameter threaded through _run_atomic_unit
  and _build_plan, and the broadcast field from the done-log line.
• In _build_plan, replace the broadcast NCCL rank loop / world_size
  calculation with single-path constants.
• Tighten the docstring/comments to describe the single cpu_serialize path.

Wire compatibility

The wire plan shape is intentionally unchanged. broadcast_local_ranks is
still present (empty), comm_ranks are all 0, and world_size is 1 — the
exact values the cpu_serialize-only path already produced. The MILES
run_sync_session plan-key validator sees no difference.

Net: +20 / -60 lines, no behavior change on the live path.

[JunzheJoe]

Evidence for the "[need discussion]" from the F1-F12 review's deep pass over both sides of this path:

• The path is double-guarded dead: service-side sync_selected_workers raises NotImplementedError when broadcast_set is non-empty, and miles-side _dispatch_nccl_broadcast has its own P1-8 self-guard raising before any receiver setup. Neither side can execute.
• _build_plan's comm_ranks construction and world_size computation therefore always take the fallback branch (world_size is always 1).
• The get_free_port + SharedStorage try_put machinery runs on every sync solely to populate master_addr/port for this dead path — and its claims are never released (see my comment on Release Miles sync port claims #22). Deleting the broadcast path would let the port-claim block go too (or be gated behind the future broadcast implementation), which simplifies Release Miles sync port claims #22's fix to nothing.

So +1 to deletion from our side; the sender-side NCCL work is cleanly re-addable later and the plan-shape (SyncSessionPlan) can keep the fields as reserved if wire-compat matters.

[TianyeGGBond]

Update on the "[need discussion]" — leaving this open rather than merging or closing it, so the team can make the call.

Since opening this I'd lean the other way: keep the broadcast path. It's the normal, faster GPU transport, and the reason it's unimplemented isn't that we don't want it — it's that we don't currently have the setup to test the sender-side NCCL. Deleting it now means re-adding it later, so I'd rather leave it guarded behind NotImplementedError as an explicit placeholder.

@JunzheJoe your deletion evidence stands — the path really is double-guarded dead today, and the port-claim machinery really does run every sync for it. So this is a judgement call, not a correctness dispute, and the two PRs are mutually exclusive:

• Keep broadcast → merge Release Miles sync port claims #22 (now reopened with the failure/timeout release hardening from your review note); drop this PR.
• Delete broadcast → merge this PR; Release Miles sync port claims #22 becomes unnecessary, since the port claim disappears with it.

My vote is the first. Leaving this open so it's an explicit team decision rather than me unilaterally deleting a capability we intend to use.