docs: state MPI rank placement precisely, use explicit exec placeholders

Signed-off-by: Yuan Chen <yuanchen97@gmail.com>

Author: yuanchen8911

docs/user/fabric-attached-training.md

@@ -263,8 +263,9 @@ Also TrainJob-expressible. AICR fixes the resource name and the value is always
 primary interface. AICR's tested AKS runtime sets it, as does the EKS one — on
 a multi-NIC node, leaving NCCL to guess can send rendezvous traffic down an
 interface that cannot carry it. `eth0` assumes the pod's primary interface is
-named that; under `hostNetwork` or a non-standard CNI it may not be. Confirm on
-a running pod with `kubectl exec ... -- ip route get 1.1.1.1` and pin whatever
+named that; under `hostNetwork` or a non-standard CNI it may not be. Confirm
+on a running pod with
+`kubectl exec -n <namespace> <pod> -- ip route get 1.1.1.1` and pin whatever
 that reports.
 
 The same repeat-every-resource caveat applies.
@@ -307,8 +308,9 @@ kubectl logs -n <namespace> -c node --tail=-1 --prefix \
 
 This selects the `node` replicated job, which is where a node-only runtime such
 as `torch-distributed` prints the banner. If your runtime uses an MPI launcher —
-as AICR's tested AKS runtime does — the ranks are aggregated in the `launcher`
-pod and the `node` pods run only sshd, so select
+as AICR's tested AKS runtime does — the rank processes still execute on the
+`node` pods, but they are started over sshd and `mpirun` aggregates their
+stdout in the `launcher` pod, so select
 `jobset.sigs.k8s.io/replicatedjob-name=launcher` instead. A grep against `node`
 on such a runtime finds nothing, which is not evidence of socket fallback.