Document ModelExpress sample and compute-plane add-on inventory

Description

NVCF needs a public, reproducible ModelExpress sample for self-managed compute
planes. The sample should adapt a validated deployment pattern to the current
public Dynamo and ModelExpress interfaces. It should explain when peer-to-peer
model weight distribution improves Dynamo scale-out cold starts.

Document ModelExpress as an optional integration that is disabled by default.
Cover supported runtime and add-on versions, required GPU networking and worker
image capabilities, configuration, rollout, verification, fallback behavior,
troubleshooting, and cleanup. Keep the primary path provider-neutral, with
targeted InfiniBand, RoCE, and AWS EFA guidance when configuration differs.

Publish a sample for ModelExpress without explicitly including it in the
compute-plane stack. Compute-plane stack inclusion is out of scope for now.

Definition of Done

• Public NVCF documentation includes a runnable ModelExpress sample for a
  Dynamo workload on a self-managed compute plane.
• The guide covers prerequisites, configuration, scale-out behavior,
  verification, fallback behavior, troubleshooting, and cleanup.
• Supported versions, worker image contents, NIXL/RDMA requirements, RBAC,
  secrets, and provider-specific network settings are explicit.
• ModelExpress remains optional and disabled by default, with no behavior
  change for existing compute-plane installations.
• The docs navigation and optional enhancement index link to the new guide.
• Documentation, manifest generation, render checks, and an end-to-end
  scale-out validation pass for the documented configuration.

Resources (optional)

• Related documentation request: #108
• ModelExpress
• Dynamo ModelExpress guide
• Dynamo and ModelExpress P2P example
• NVCF software manifest

Start with docs/user/manifest.md and the referenced Dynamo and ModelExpress guides, then inspect the existing docs navigation and optional enhancement index. Use the linked P2P example to understand the documented deployment pattern. Done means a linked, runnable provider-neutral sample with explicit prerequisites, configuration, verification, fallback, troubleshooting, cleanup, and passing documentation, manifest, render, and scale-out validation checks.