refactor(recipes): aggregated / disaggregated naming, and the RDMA check on the published page

[jiejingzhangamd]

Two changes. Both were pushed after #75 merged, so neither made it in.

1. mixed / pd → aggregated / disaggregated

mixed never said what was mixed, and pd needed you to already know it abbreviates prefill/decode. aggregated / disaggregated is the vocabulary the field uses — what NVIDIA Dynamo's recipe pages use, and what someone searching for this feature will type.

Renamed across all three models, so the combination set stays comparable between them — which is the whole reason it is a fixed set:

mixed        -> aggregated          pd         -> disaggregated
mixed-kvd    -> aggregated-kvd      pd-kvd     -> disaggregated-kvd
mixed-dspark -> aggregated-dspark   pd-dspark  -> disaggregated-dspark
                                    pd-sglang  -> disaggregated-sglang

13 directories, plus every reference in prose, link text, link targets, tab labels and tab sync ids. Renaming only one model would have broken cross-model comparability; renaming the directories and leaving the prose would have left text and links disagreeing.

The API values are deliberately unchanged

role: inside each manifest is consumed by the operator and is still mixed / prefill / decode, as is DisaggMode.MIXED in the Python. Renaming those would break every deployed configuration and anything outside this repo using the CRD — a separate decision, on its own terms.

That leaves aggregated/deploy.yaml legitimately containing role: mixed, which reads like a mistake if you meet it cold. Both the repo README and the manual index now say so explicitly: the directory name is what the combination means, role: is the wire format. A reader who spots the discrepancy finds it already accounted for rather than concluding the docs are stale.

Verified: all 13 manifests still pass kubectl apply --dry-run=server; every deploy.yaml path referenced from any document exists; the manual builds clean with warnings-as-errors and all four tabs on each of the three model pages render with the new labels and sync ids.

2. The RDMA device check is now on the published page

The page told readers that ibv_devices is absent and that ibv_get_device_list is the right question — then sent them to the repo README for the command. Someone reading the docs site to find out whether their NICs are visible could not get an answer from the docs site.

The Disaggregated tab now carries both forms: a standalone probe pod for before you deploy, and the in-pod version for after. Both state why it is worth running: when the container cannot see the RDMA devices, nothing says so. Mooncake falls back to a transport that cannot cross nodes, and the symptom is a request that hangs while every pod stays Ready.

It also says which pod to run it in. The router runs the same image but is not privileged and does not mount /dev/infiniband, so it reports 0 — reproducing the exact false negative this check exists to prevent. That was observed twice during validation.

There is no pre-flight script to point at: the one added earlier was withdrawn in #74 for giving wrong verdicts in both directions, so the fabric check is documented as a command rather than a tool.

Also repaired a sentence in the validation section that an earlier edit had left spliced together mid-clause.