todo: validate external DP within prefill and decode roles #754

What was left undone:

Define and validate External DP within a Prefill or Decode role before allowing multiple members of that role into managed HTTP routing.

Provenance: reported scope request during the External LB walkthrough work. This records an explicitly deferred validation task, not a reproduced P/D runtime failure.

The current External DP experiment covers a Server role with one HTTP endpoint per DP rank. That result does not establish P/D support. P/D routing must continue to select each replica's leader until this combination has a defined contract and measured evidence.

Where it came from (PR, commit, or spec section):

• Follow-up scope identified while preparing fix(model-deployment): route External DP members and add walkthroughs #752 and its requested External LB walkthrough.
• The existing role and routing contracts are described in docs/modules/model-deployment/deployment.md, prefill-decode.md, and routing.md.
• At commit 0a1e849c9a13923677811acecb48e8f0654ef75b, modelDeploymentGroupForwardActivatable excludes Prefill and Decode roles. Their qualification cannot be inferred from the Server-role gate.

How this was known:

• The change knew — this combination is deliberately deferred from the current Server External DP work.
• Worked out afterwards

What it needs in order to run (hardware, cluster shape, driver version, credentials, tooling):

• A Kubernetes cluster with enough GPUs for both sides of the chosen fixed P/D topology.
• Official GPUStack runner images pinned by digest, with compatible engine and KV-transfer versions.
• A managed router that supports the selected P/D transfer path.
• ModelArtifact/ModelPrefetch preparation and read-only native-rank, device-allocation, endpoint and request observations.
• A separately approved runtime window if the existing test environment is no longer available.

How to verify it (the exact case or command, and the figure that would prove it):

• Define supported engine/router/transfer combinations before writing an executable manifest. Do not assume vLLM and SGLang use interchangeable flags.
• Cover P/D member counts 1/1, 2/1, 1/2 and 2/2. Keep ordinary collective followers distinct from members that actually expose HTTP.
• Define rank placement and KV-transfer destination mapping when either side has multiple HTTP ranks.
• Check the actual Router discovery set, per-role published selectors and role Services. Preserve all-member headless DNS for each collective.
• Bind native TP/DP/EP groups and physical GPU allocations to the observed Pod UIDs.
• Complete ordinary and SSE requests through the Router and prove which P and D endpoints served them. HTTP 200 alone is insufficient.
• Verify whole-group withdrawal and recovery when one member becomes unavailable. Prevent role mixing and traffic to non-HTTP followers.
• Add executable reproduction manifests and a walkthrough only after the configuration passes.

No exact GPU reproduction is claimed yet; defining the valid combination and executable recipe is part of this task.

What is unproven until then:

Managed P/D routing across multiple External DP HTTP members, correct rank-to-rank KV transfer, and group failure handling for that combination.

Hybrid LB and multi-port External DP are outside this task. Native online DP/EP collective resizing is also outside this task.