[DeepSeek Harness 3/8] Let users onboard and use the accepted Web and headless surfaces

## Summary

Let protected candidate users onboard DeepSeek Harness and use exactly the Web and headless surfaces accepted by Gate 1.

Parent epic: #9328

Depends on:

- #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**;
- any generic browser-authentication prerequisite explicitly required by Gate 1.

Gate 4 owns durable state and recovery. Gate 5 owns managed inference. Gate 6 owns the complete trust policy. Gate 7 owns exact live release qualification. Gate 8 alone owns public activation.

## Problem Statement

An image containing `dsh` is not yet a usable NemoClaw agent.

NemoClaw must persist the candidate agent identity, start and observe the accepted long-running Web process, expose only the accepted browser boundary, dispatch the accepted headless command, supervise shutdown, and report actionable failures.

The current runtime model distinguishes gateway and terminal agents. A gateway manifest may carry a `headless_command`, but the existing `nemoclaw ... agent` passthrough rejects arbitrary gateway agents. DeepSeek Harness also has no shipped terminal UI.

The upstream Web server binds loopback and has Host/Origin checks, but no TLS or user authentication. Treating `dashboard.auth: session` as an authentication implementation would expose a false security claim.

## Desired Behavior

Protected candidate onboarding selects the exact image from Gate 2 and records `deepseek-harness` as the agent runtime independently from the compute runtime.

NemoClaw starts only the surfaces accepted by Gate 1:

- When Web is accepted, the DSH server remains loopback-bound inside the sandbox, uses the accepted internal port, passes a real API/WebSocket readiness probe, and is reachable only through the accepted host-forward and browser boundary.
- When headless is accepted, one documented public candidate command forwards the task, stdout, stderr, exit status, cancellation, and timeout semantics without executing a shell-composed manifest string.
- When Gate 1 selects headless-only, NemoClaw does not start, advertise, forward, or document a dashboard.

The implementation remains generic. It may add a reusable gateway-with-headless capability, but must not add a `deepseek-harness` name comparison to shared dispatch, lifecycle, or compute-runtime code.

## Accepted browser modes

Implementation must follow exactly one accepted Gate 1 mode.

### Authenticated Web

- The named authentication component must authenticate before requests reach DSH API or WebSocket routes.
- Host/Origin validation remains defense in depth and is not the login mechanism.
- Anonymous, replayed, malformed, cross-origin, and direct-to-internal-port requests fail according to the accepted threat model.
- `dashboard-url`, remote SSH guidance, and token/session handling must match the actual authentication mechanism.

### Loopback-only unauthenticated Web

- The manifest declares `auth: none`, not `session` or `url_token`.
- DSH binds `127.0.0.1` inside the sandbox; NemoClaw's host forward binds only the accepted loopback address.
- No LAN, wildcard, public, or automatically shared URL is advertised.
- Status and `dashboard-url` clearly state that possession of local loopback access is the access boundary.
- Host/Origin checks are described only as browser reachability checks.

### Headless-only

- No dashboard metadata, forward, browser command, Web process, or browser support claim is emitted.
- Dashboard commands fail with an actionable headless-only explanation.

## Headless dispatch modes

Implementation must follow the Gate 1 choice:

- A generic gateway-with-headless dispatch path may use `runtime.headless_command` for any qualifying manifest while preserving current OpenClaw, Hermes, terminal-agent, JSON, stdin, signal, and readiness behavior; or
- the supported command may use the existing sandbox exec surface with an exact argv contract.

Do not classify DSH as terminal merely to reach terminal passthrough. Do not treat `dsh web` as an interactive terminal command. Manifest commands must be structured argv or pass the current simple-token validation without quoting or shell evaluation.

## Process and concurrency contract

Use the shared or isolated `$DSH_HOME` model accepted by Gate 1.

If Web and headless can run concurrently against shared state, prove that profile initialization, profile symlink repair, settings reads, session creation, attachment writes, and Web `storages/` updates do not race or corrupt state. If isolation was selected, expose the documented separation and do not claim that sessions or attachments automatically appear across surfaces.

One surface must not silently replace the other surface's managed configuration. Both must receive the same root-owned final overlay and accepted policy inputs.

## Scope

- Candidate-only interactive and non-interactive onboarding inputs.
- Registry persistence of `deepseek-harness` and the selected compute-runtime identity.
- Runtime-kind, gateway command, optional headless command, health, dashboard, and forward metadata.
- Web startup, readiness, logs, graceful shutdown, stale-process cleanup, and port ownership when accepted.
- Browser authentication or loopback-only exposure exactly as accepted.
- Host forwarding, `dashboard-url`, SSH guidance, conflict detection, recovery hints, and cleanup for the accepted browser mode.
- Headless task dispatch, captured output, exit status, timeout, cancellation, stdin posture, and help behavior.
- Shared generic dispatch changes required for a gateway runtime with headless execution.
- Actionable errors for missing artifacts, bad configuration, bind failure, failed API/WebSocket readiness, failed authentication, unavailable headless mode, and unsupported surfaces.
- Candidate launch and surface contract tests without public activation.

## Constraints and Non-goals

- Do not make DeepSeek Harness publicly selectable; Gate 8 owns activation.
- Do not claim user authentication from Host, Origin, trusted-host, loopback bind, or NemoClaw manifest metadata.
- Do not bind DSH or its host forward to `0.0.0.0` in v1.
- Do not expose the internal DSH port directly as a remote/public service.
- Do not add a DeepSeek Harness-specific gateway recovery, host-forward, Docker, Podman, or process-supervision branch.
- Do not regress OpenClaw, Hermes, LangChain Deep Agents Code, Pi, or external terminal-runtime dispatch behavior.
- Do not use shell interpolation for the headless task or manifest command.
- Do not assume Web and headless can safely share state.
- Do not allow first-use profile creation to install packages or contact a registry.
- Do not treat a successful static `/` response as full runtime readiness.
- Do not claim managed-inference, state-recovery, full policy, or release qualification completion in this issue.

## Observable acceptance tests

### Candidate onboarding and identity

- Protected candidate onboarding selects the exact Gate 2 digest without a host build and persists `deepseek-harness` separately from the compute runtime.
- Resume after a bounded onboarding interruption retains both identities and does not start an unaccepted surface.
- Public onboarding and ordinary agent choices remain unable to select DeepSeek Harness.
- Inventory, initial status, logs, and diagnostics identify the candidate runtime and accepted surfaces accurately.

### Web, when accepted

- DSH binds only the accepted loopback address and internal port.
- NemoClaw owns one collision-checked host-loopback forward and records its ownership.
- Readiness proves the frontend, API request path, and API WebSocket/downlink path from the browser-facing route; a static frontend with a broken API remains unready.
- Startup failure, port collision, malformed trusted-host input, failed WebSocket, and premature process exit produce stable actionable errors.
- `SIGTERM` and `SIGINT` drain the DSH process, close upgraded sockets, and reap accepted child/background processes within the deadline.
- Restarting the candidate does not leave a stale listener or duplicate forward.
- An authenticated mode denies unauthenticated and invalid-session HTTP and WebSocket requests before DSH operations execute.
- A loopback-only unauthenticated mode rejects wildcard/LAN binding and prints no authentication claim or remotely shareable URL.
- Cross-origin and untrusted-host negative cases fail without being treated as the user-auth boundary.

### Headless, when accepted

- A deterministic keyless/mock task reaches `dsh --profile headless`, produces the expected stdout, writes diagnostics only to stderr, and returns the upstream exit status.
- Invalid arguments and missing tasks fail nonzero with stable help.
- The wrapper preserves bounded timeout and signal-derived exit behavior and does not leave a DSH or child process running.
- A pipe or explicitly accepted stdin mode follows the documented contract; no interactive TTY is accidentally attached to captured dispatch.
- Task text containing spaces, quotes, leading dashes, Unicode, or shell metacharacters arrives as argv data and is never shell-evaluated.
- Gateway-with-headless support, if added, is manifest-derived and passes regression tests for every existing agent kind.

### Surface concurrency

- The accepted shared-home mode runs Web and headless concurrently under a deterministic write workload without profile, settings, session, attachment, or storage corruption; or
- the accepted isolated-home mode proves and documents that state remains separated.
- Starting headless cannot replace the running Web process's final managed overlay, port, or settings authority.

## Required evidence

Attach or link candidate evidence containing:

- NemoClaw commit, Gate 1 decision revision, package integrity, image digest, architecture, OpenShell version, and compute-runtime identity;
- sanitized startup argv and effective surface configuration;
- process tree, bind addresses, internal/public ports, health probes, and host-forward ownership;
- the actual browser authentication mode and negative-request results;
- API and WebSocket readiness results;
- headless argv, stdout/stderr, exit, timeout, and cancellation results;
- shared/isolated-home concurrency results;
- regressions for existing gateway and terminal agents;
- confirmation that public selection and the shipped cohort remain unchanged.

## Documentation impact

- Add maintainer-facing candidate instructions for starting, probing, stopping, and diagnosing each accepted surface.
- Add exact command help and actionable error copy for candidate paths.
- Document the actual browser boundary without calling Host/Origin checks authentication.
- Document whether Web and headless sessions share state.
- Defer public onboarding and support documentation to Gate 8.

## Acceptance Criteria

- [ ] Gate 1, Gate 2, and every named generic authentication prerequisite are complete.
- [ ] Protected onboarding records the exact candidate image, `deepseek-harness` identity, and compute-runtime identity without public activation.
- [ ] Only Gate 1-accepted surfaces start or appear in commands, status, diagnostics, and help.
- [ ] Web startup, full readiness, shutdown, logs, port ownership, forward behavior, and error handling pass when Web is accepted.
- [ ] The browser boundary implements the accepted authenticated, loopback-only unauthenticated, or headless-only contract without false authentication claims.
- [ ] Headless dispatch implements the accepted public command, structured argv, output, exit, timeout, cancellation, and stdin contract.
- [ ] Any gateway-with-headless extension is generic and preserves all existing agent behavior.
- [ ] Shared or isolated Web/headless state behavior matches Gate 1 and passes its concurrency test.
- [ ] Both accepted surfaces receive the root-owned final configuration overlay.
- [ ] No first-use path installs packages or contacts a registry.
- [ ] Public selection and the active shipped-image cohort remain unchanged.
- [ ] Candidate evidence and maintainer surface documentation are complete and credential-free.

## Category

Feature

## Checklist

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

Start with the Gate 1 decision, its named prerequisites, and the existing gateway and terminal dispatch entry points. Trace protected candidate onboarding, runtime.headless_command, and the dsh --profile headless command before running the candidate launch and surface contract tests. Done means only accepted surfaces start, Web and headless contracts pass, state behavior matches Gate 1, and existing agent regressions remain clear.

Written by the indexing model from the issue text.