todo: render host-fabric access into engine Pods on RDMA and EFA pools

What is left undone

On a host-fabric transport (RDMA or EFA), the operator renders what the fabric needs —
hostNetwork, /dev/infiniband, IPC_LOCK/SYS_RESOURCE, and on EFA the device resource request
that makes those nodes openable — into the backend's member Pods only. The engine Pods (vLLM /
SGLang) that consume the pool get none of it: the injection webhook renders the transport name
(MOONCAKE_PROTOCOL / mooncake.json protocol) and nothing the fabric needs.

The member-side shape has moved since this was filed. #347 removed the /opt/amazon/efa hostPath
and its LD_LIBRARY_PATH: the image now carries a matched libfabric and the member requests the
EFA device resource instead. That changes what "the same access" would mean for an engine Pod — a
device request rather than a host mount — and not the fact that engines have none of it.

On TCP that distinction costs nothing — it is plain pod networking. On RDMA or EFA, an
engine that is to move bytes over the fabric needs the same device access on its own Pod, and today
its transfer engine either fails to install the transport or silently falls back.

This gap predates EFA — RDMA has always had it; EFA inherits it. The enum's own bar ("only
TCP has been exercised end to end") is downstream of exactly this.

The central question is unmeasured, and the environment for it is gone

Which of the two it is has never been read. "Fails to install the transport or silently falls
back" is a disjunction, and the branches differ in how bad this is: a loud failure is a deployment
that does not start; a silent fallback is a deployment that serves at TCP speed while its object
says EFA. Nothing here distinguishes them.

Answering it needs EFA hardware and engine Pods in one cluster. The round that had both did not
measure it, and that cluster has been destroyed. Recorded so the next reader does not take the
absence of a reading for a reading.

What it would take is the same shape as the member-side work: a pool on real EFA, an engine Pod
scheduled against it, and the engine's own log read for which transport it installed.

What deciding this looks like

• Whether engine Pods should get fabric access at all: it grants hostNetwork and
  capabilities to tenant-adjacent workloads, a much wider blast radius than the cluster-scoped
  member DaemonSet. The member-side rule "a privilege is requested, never inferred" has no
  obvious engine-side spelling — there is no field on the engine's owning object that asks for
  it.
• If yes, how: a per-pool or per-backend opt-in the injection webhook can see at mutate time,
  rendering the same host-fabric base (and the EFA extras) into the engine container; or a
  documented node-level answer (device plugin / CNI) the operator stays out of.
• What the honest interim is: the docs now state the gap on both pages a reader would look
  for it (docs/kv-cache/backend.md, docs/reference/kv-cache-injection.md). If the decision is
  "members only, engines stay on TCP", that should be said as a rule, not left as an absence.

References

• Member-side rendering (the half that exists): applyMemberFabric in
  pkg/worker/kvcache/mooncake/member_workload.go.
• Engine-side injection (the half that only names the transport):
  pkg/worker/kvcache/inject/engine.go, pkg/worker/webhooks/worker/pod_kv_cache_resolve.go.

Read applyMemberFabric in pkg/worker/kvcache/mooncake/member_workload.go and the engine injection paths in pkg/worker/kvcache/inject/engine.go and pkg/worker/webhooks/worker/pod_kv_cache_resolve.go. Determine on real EFA hardware whether engine Pods fail or fall back, then decide whether and how fabric access should be granted. Done means the policy is implemented or explicitly documented, with the relevant docs updated.