Release Miles sync port claims

[TianyeGGBond]

Context

MilesModelUpdateService claims NCCL rendezvous ports in SharedStorage while building sync plans. The MILES path recorded the claim but never released it after the cache-owner transport completed, so successful syncs could leave stale MASTER_ADDR_PORT:* keys behind over a long-running job.

[JunzheJoe]

Reviewed this as part of the F1-F12 code review — supportive. Two notes before merge:

1. The failure/timeout path still leaks the claim. This PR releases on the successful-transport path (_release_port_claim fires right after run_sync_session returns — correct placement, since the port is only needed for the NCCL rendezvous during transport). But if run_sync_session raises, or the atomic unit's asyncio.wait_for cancels mid-flight (_cancel_inflight fires ray.cancel on the inflight refs but never releases the port), _release_port_claim is skipped and the claim lingers until orchestrator.kill_pipeline's delete_port_claims. Since every sync claims a fresh MASTER_ADDR_PORT:{addr}:{port} key, repeated failures still grow the claim table, and OS port reuse can collide with stale claims and burn the 8-attempt retry budget. Suggestion: keep the current post-transport release, and additionally release in the timeout/cancellation handler (or restructure as try/finally around the transport step).

2. The claim currently serves a dead path. master_addr/port is only consumed by the NCCL broadcast transport, and that path is double-guarded with NotImplementedError (service-side sync_selected_workers L177-190, miles-side _dispatch_nccl_broadcast P1-8 self-guard). cpu_serialize never touches the port. An alternative to hardening the release: skip claiming entirely until broadcast lands — which would also intersect with delete unimplemented broadcast transport path [need discussion] #24's discussion.