Publish the complete Deep Agents Code managed image (ghcr.io/nvidia/nemoclaw/langchain-deepagents-code-sandbox) like openclaw-sandbox and hermes-sandbox

### Problem Statement

Stock Deep Agents Code onboarding is already buildless: it resolves `ghcr.io/nvidia/nemoclaw/langchain-deepagents-code-sandbox` by the release's exact managed-image digest (quickstart, "stock Deep Agents Code onboarding normally uses the release's exact managed-image digest"), and the image is built, validated, attested, and staged in the same six-candidate cohort barrier as `openclaw-sandbox` and `hermes-sandbox`. `SHIPPED_MANAGED_IMAGE_AGENTS` in `src/lib/onboard/managed-image/contract.ts` already names `langchain-deepagents-code` a shipped agent.

But the registry carries **no consumer pointer**: all tags on `langchain-deepagents-code-sandbox` are `cohort-ghrun-*` qualification candidates or buildcache — no `:`, no `:`, no `latest` (verified 2026-09-09: 370 tags, zero release markers). A downstream custom image (`nemo-deepagents onboard --from ` is the documented separate path) has nothing to `FROM` by name, and there is no discoverable release-to-digest mapping.

Since #11228 / #11298 the pointer machinery is shared: `shipped_agents=(openclaw hermes)` in the `managed-images.yaml` staging and pointer-promotion steps. Deep Agents Code was deliberately left cohort-only there pending its own publication decision — this issue is that decision. It also closes the residual inconsistency that the workflow's pointer set is narrower than the source contract's `SHIPPED_MANAGED_IMAGE_AGENTS`.

### Desired Behavior

`ghcr.io/nvidia/nemoclaw/langchain-deepagents-code-sandbox:` (and `:`, and their digests) published for every release alongside `openclaw-sandbox` and `hermes-sandbox`, from the same promote lane that already stages it.

Before: a downstream Deep Agents Code Dockerfile must reproduce `agents/langchain-deepagents-code/Dockerfile` against a version-matched NemoClaw checkout, or extract the digest NemoClaw's own buildless onboarding uses.
After: `FROM ghcr.io/nvidia/nemoclaw/langchain-deepagents-code-sandbox@sha256:…`, add tools/config, `nemo-deepagents onboard --from Dockerfile`, exactly like the OpenClaw and Hermes paths.

### Scope and Exclusions

Includes: extending the shipped-agent pointer list to `langchain-deepagents-code` in both `managed-images.yaml` sites, the matching publication-test coverage, and a one-line docs note for the custom-image path. Excludes: any change to `agents/langchain-deepagents-code/Dockerfile`, the dcode runtime, or onboarding behavior (stock onboarding already consumes the digest). If Deep Agents Code is intentionally unpublished, the ask reduces to documenting that and the supported downstream path.

### Ongoing Ownership

NemoClaw managed-images owners (the lane already builds and stages this artifact). Downstream consumer: the VSS blueprint team (NVIDIA-AI-Blueprints/video-search-and-summarization), same as the Hermes case.

### Placement and Support Expectations

Core NemoClaw: the existing managed-image publication extended to the third agent the workflow already ships internally. Support expectation identical to `openclaw-sandbox` and `hermes-sandbox`: per-release tag plus digest.

### Validation Plan

- `docker manifest inspect ghcr.io/nvidia/nemoclaw/langchain-deepagents-code-sandbox:` resolves for the release that ships the change, both platforms.
- `nemo-deepagents onboard --non-interactive --name --from ` with a Dockerfile that is only `FROM` the published digest reaches a healthy sandbox (`nemo-deepagents status`).
- The managed-image activation e2e passes against the published tag rather than a locally staged digest.

### Compatibility Requirements

Same matrix as the other shipped agents: linux/amd64 + linux/arm64, releases from the one shipping this change onward.

### Security or Privacy Impact

None new: the artifact is already built, attested (SLSA/SPDX), qualification-gated, and anonymously pull-proved per cohort; this only adds consumer pointers to it. Downstream images inherit the managed startup and route-probe helpers instead of re-implementing them — the same downstream-drift reduction as #11228.

### Implementation Idea

Extend `shipped_agents=(openclaw hermes)` to include `langchain-deepagents-code` at both sites in `managed-images.yaml` (staging alias recording and pointer promotion), widen the exact-reference repository pattern accordingly, and update the publication tests that currently assert Deep Agents Code receives no consumer pointer.

### Category

Feature

Start with the two shipped-agent entries in managed-images.yaml and the shipped-agent contract in src/lib/onboard/managed-image/contract.ts, then read the publication tests that currently exclude Deep Agents Code. Confirm how the staging alias, pointer promotion, and exact-reference repository pattern work for openclaw and hermes. Done means release and revision pointers publish for both platforms, the publication tests pass, and the documented digest-based Dockerfile onboarding reaches a healthy sandbox.

Written by the indexing model from the issue text.