[DeepSeek Harness 8/8] Activate the qualified runtime and publish supported operations

## Summary

Activate DeepSeek Harness as a supported open-source NemoClaw agent only after Gates 1–7 are complete, and publish one canonical operations, compatibility, security, recovery, and upgrade contract bound to the accepted exact-candidate evidence.

Parent epic: #9328

Depends on completion and accepted receipts for:

- #9329, **[DeepSeek Harness 1/8] Accept product scope, ownership, threat model, and compatibility matrix**;
- #9330, **[DeepSeek Harness 2/8] Produce a reproducible DeepSeek Harness candidate runtime**;
- #9331, **[DeepSeek Harness 3/8] Let users onboard and use the accepted Web and headless surfaces**;
- #9332, **[DeepSeek Harness 4/8] Preserve and recover accepted DeepSeek Harness state**;
- #9333, **[DeepSeek Harness 5/8] Run DeepSeek Harness through managed inference without provider credentials**;
- #9334, **[DeepSeek Harness 6/8] Enforce the accepted DeepSeek Harness trust and policy boundary**;
- #9335, **[DeepSeek Harness 7/8] Qualify the exact candidate on AMD64 and ARM64**.

Documentation may begin after Gate 1 accepts the product surface, but this issue cannot complete until Gate 7 provides exact native AMD64 and ARM64 qualification evidence.

## Open-source scope

This issue governs the public NemoClaw product surface, documentation, and release artifacts. It does not establish or require approval from an organization-specific deployment program. Organizations may impose separate deployment policies on the released open-source project.

## Problem Statement

DeepSeek Harness can exist as a pinned, tested dark candidate without being safe to advertise or select. A partial activation could expose an agent whose architecture digest, managed route, policy, state behavior, browser boundary, documentation, or qualification receipt does not agree with the released catalog.

The upstream harness is prerelease software and may introduce compatibility-breaking package or state changes. Users need exact supported commands, limitations, recovery behavior, and upgrade expectations. They must also be able to distinguish the DeepSeek Harness runtime from using a DeepSeek model with another NemoClaw agent.

No earlier gate owns the final atomic change that binds the accepted receipt, enables selection, publishes the complete managed-image cohort, updates every supported inventory, and releases the operational documentation.

## Desired Behavior

After every prerequisite closes, one final activation change:

- binds the accepted Gate 7 receipt to the exact package, image, configuration, policy, state, inference, surface, and architecture identities;
- makes canonical agent ID `deepseek-harness` selectable through interactive onboarding and `nemoclaw onboard --agent deepseek-harness`;
- publishes the complete accepted AMD64/ARM64 managed-image cohort atomically;
- exposes the Gate 1 Web/headless product surfaces through the supported commands and browser boundary;
- updates inventory, status, logs, diagnostics, lifecycle, help, docs, AI documentation routes, changelog, and release material;
- documents exact support, known limitations, state behavior, troubleshooting, recovery, and upgrade/rollback rules.

If any prerequisite, architecture, identity, publication, documentation, or release-blocking qualification check fails, DeepSeek Harness remains unadvertised and unselectable. There is no partial platform or architecture activation.

## Supported operations to publish

The canonical documentation and command help must cover only behavior accepted and qualified in Gates 1–7:

- installation and buildless stock onboarding from exact managed-image digests;
- interactive and non-interactive agent selection;
- starting, reaching through its accepted access/authentication boundary, stopping, and troubleshooting the accepted Web surface, or the explicit absence of Web support;
- the exact supported headless invocation and stdout/stderr/exit contract;
- managed provider/model selection and `inference.local` credential custody;
- inventory, status, health, logs, diagnostics, restart, and graceful shutdown;
- workspace, sessions, attachments, settings, profiles, plugins, skills, and other state classifications;
- snapshot, backup, restore, rebuild, recovery, upgrade, rollback, and destroy behavior;
- accepted Docker, Linux architecture, provider, API-family, model-validation, tool, plugin, profile, browser, filesystem, network, and telemetry matrix;
- stable errors and remediation for every unsupported or denied surface.

## Activation and publication checks

The final change must make these identities agree exactly:

- supported agent catalog and canonical manifest;
- candidate/accepted qualification-receipt authority;
- package version, npm integrity, lockfile, compiled artifacts, and native dependency closure;
- OCI index and architecture digests in the complete managed-image cohort;
- startup profile, generated configuration, state manifest, trust matrix, and policy digest;
- browser/headless surface and command metadata;
- managed-inference adapter, API family, validation rules, and qualification model evidence;
- public docs, command help, troubleshooting, changelog, and release notes;
- Gate 7 machine-readable receipts for native AMD64 and ARM64.

CI must reject missing, stale, mixed, or partial identities. A failure to publish either architecture must not leave DeepSeek Harness selectable or advertised.

## Upgrade contract

Runtime self-update and floating package versions remain unsupported.

Each future DSH package or managed-image change must return to candidate state and obtain a new exact qualification receipt. State migration is supported only for version pairs explicitly accepted and tested by the Gate 1 compatibility rules. An unqualified prerelease change must fail before destructive mutation and leave the current sandbox recoverable through the documented rollback path.

The initial release documentation must state the exact package version and any same-version rebuild, cross-version restore, downgrade, and rollback limitations. It must not promise arbitrary migration between upstream release candidates.

## Required release verification and evidence

1. Run the complete release-blocking Gate 7 qualification from the exact activation commit or prove that the activation-only diff cannot change any qualified identity, using the repository's accepted immutable-receipt rule.
2. Install the release candidate on fresh native AMD64 and ARM64 hosts through the public installation and onboarding commands.
3. Verify public selection, exact digest resolution, supported Web/headless behavior, managed route, status, diagnostics, recovery, and destroy from released artifacts without repository edits or host builds.
4. Inject a controlled publication failure for one architecture and prove catalog, selection, docs/release metadata, and image publication cannot present a partial cohort.
5. Exercise rollback from a failed activation or upgrade and prove the prior supported runtime and accepted user state remain recoverable.
6. Run secret and prohibited-state scans over release images, metadata, docs, logs, evidence, and published artifacts.
7. Record release URLs, immutable digests, accepted receipts, CI runs, documentation build results, reviewer receipts, and rollback-test results in one bounded release manifest.

## Documentation requirements

- Add canonical user docs for onboarding, Web/headless use, managed inference, operations, recovery, upgrades, security boundaries, troubleshooting, compatibility, and known limitations.
- State clearly that DeepSeek Harness is an agent runtime; selecting it is distinct from selecting a DeepSeek model for another agent.
- State that stock onboarding pulls an exact managed-image digest and does not build a repository Dockerfile on the user host.
- Name the exact supported architectures and compute runtime. Do not advertise Podman or another deferred runtime.
- Name enabled and disabled DSH tools and extension surfaces, including plugins, profiles, skills, MCP, Web/search, telemetry, package installation, self-update, workflows, subagents, and background work.
- Explain the accepted browser authentication or loopback-only limitation without treating Host or Origin validation as authentication.
- Explain persistent, reconstructed, discarded, and prohibited state, including credential and executable-trust handling.
- Link the accepted Gate 7 task, oracle, machine-readable receipts, and release manifest.
- Add changelog and release-note entries with the exact package and supported matrix.
- Update applicable CLI help, supported-agent inventory, troubleshooting routes, and AI documentation routes.
- Run `make docs` and `python scripts/docs-to-skills.py docs/ .agents/skills/ --prefix nemoclaw-user --dry-run`.
- Obtain and record independent documentation-writer review of the complete DeepSeek Harness code and documentation surface.

## Constraints and Non-goals

- Do not activate while any Gate 1–7 prerequisite or acceptance receipt is incomplete.
- Do not publish or advertise a partial architecture cohort.
- Do not use a floating package, mutable image tag, runtime self-update, first-boot package installation, manual sandbox edit, or unqualified state migration.
- Do not change a qualified package, image, configuration, policy, state, inference, or surface identity inside an activation-only change without returning to Gate 7.
- Do not claim support outside the accepted compute-runtime, architecture, provider, API-family, model-validation, browser, tool, plugin, profile, filesystem, network, telemetry, or lifecycle matrix.
- Do not call Host or Origin checks browser authentication.
- Do not add a DSH-specific compute-runtime, lifecycle, recovery, snapshot, inference-provider, or destroy branch.
- Do not make organization-specific deployment approval a prerequisite for the public open-source release.

## Acceptance Criteria

- [ ] Gates 1–7 are complete and their accepted decisions and receipts are linked.
- [ ] The exact Gate 7 runtime, image, configuration, policy, state, inference, surface, and architecture identities match the activation commit.
- [ ] DeepSeek Harness is present in the supported inventory with canonical ID `deepseek-harness`.
- [ ] Interactive onboarding can select DeepSeek Harness.
- [ ] `nemoclaw onboard --agent deepseek-harness` selects and persists the exact supported agent.
- [ ] Stock onboarding pulls exact architecture digests without a host Dockerfile build or first-boot package installation.
- [ ] The atomic managed-image cohort contains every accepted AMD64 and ARM64 digest and cannot publish partially.
- [ ] Candidate receipt authority, catalog, manifest, package, startup profile, state manifest, generated configuration, policy, and image identities agree.
- [ ] Public Web and headless behavior exactly matches Gate 1 and Gate 7; unsupported surfaces remain unavailable with actionable errors.
- [ ] Released operation, inference, state, security, recovery, upgrade, and rollback behavior passes on fresh native AMD64 and ARM64 hosts.
- [ ] A failed activation, architecture publication, or upgrade leaves no partial advertisement and preserves the documented rollback path.
- [ ] Release artifacts, logs, docs, and evidence contain no provider credential, browser token, or prohibited state.
- [ ] Canonical docs and command help cover every supported operation and limitation listed above.
- [ ] Docs distinguish the DeepSeek Harness runtime from DeepSeek model-provider support.
- [ ] `make docs` and the docs-to-skills dry run pass.
- [ ] Independent documentation-writer review is recorded.
- [ ] Changelog, release notes, release manifest, immutable digests, CI links, and Gate 7 receipts are published together.

## Category

Feature

## Checklist

- [x] I searched existing issues and this is not a duplicate.
- [x] I described the problem and desired behavior.

Start by checking Gates 1–7, their linked issues, accepted receipts, and the supported-agent inventory before changing activation or publication behavior. Verify the public entry point `nemoclaw onboard --agent deepseek-harness`, then run the listed release checks, `make docs`, and `python scripts/docs-to-skills.py docs/ .agents/skills/ --prefix nemoclaw-user --dry-run`; done requires matching receipts, atomic AMD64/ARM64 publication, complete docs, and rollback evidence.

Written by the indexing model from the issue text.