[Epic] Replace onboarding inputs with one declarative configuration

## Problem Statement

Replace NemoClaw's overlapping install and onboarding inputs with one versioned, declarative configuration file.

A user should describe one desired deployment: the agent, sandbox environment, inference runtime and model, network policy, integrations, and operational settings. NemoClaw should validate that document and converge the deployment through one onboarding engine.

Today, users express the same intent through interactive menus, CLI flags, `NEMOCLAW_*` variables, Express logic, and serving profiles. These paths require precedence rules, conflict checks, duplicated validation, and many input combinations. The result is difficult to understand, automate, test, and maintain.

This epic authorizes a product-surface redesign only after maintainers record an **Accept** decision. The redesign must reduce onboarding code and concepts. Adding a configuration file beside all existing interfaces does not satisfy this epic.

## Desired Behavior

NemoClaw has one public desired-state contract:

```bash
nemoclaw onboard --config nemoclaw.yaml
```

The file specifies the complete non-secret deployment configuration, including:

- Agent and sandbox name.
- Host and sandbox runtime requirements.
- Inference provider or serving profile, model, endpoint, and topology.
- Network policy tier and presets.
- GPU selection and read-only host mounts.
- Messaging, web search, tools, and observability.
- Custom image inputs when supported.

The file references credentials by source. It does not contain credential values.

NemoClaw validates the schema, resolves host compatibility and catalog references, prints a redacted plan, and applies that plan through one engine. Unknown fields, conflicting selections, unsupported combinations, and missing credential references fail before host or sandbox mutation.

Interactive or graphical setup may generate this file. It must not create a separate execution path.

Lifecycle controls such as validation, planning, apply, and recovery may remain as command options because they control execution rather than desired state.

Existing configuration flags and selection environment variables become migration inputs only. They must converge into the same contract and be removed after a defined compatibility period. Credential environment variables may remain as secret sources.

### Concrete example

```yaml
apiVersion: nemoclaw.nvidia.com/v1
kind: Sandbox
metadata:
name: my-assistant
spec:
agent: openclaw
runtime:
sandbox: docker
gpu:
mode: auto
inference:
provider: openai
model:
credential:
env: OPENAI_API_KEY
network:
tier: balanced
webSearch:
provider: none
messaging: []
observability:
enabled: true
```

## Scope and Exclusions

### Included

- Define one versioned schema for complete onboarding desired state.
- Separate desired state, secret resolution, detected host facts, and execution state.
- Route install and onboarding decisions through one schema, validation path, plan, and apply engine.
- Preserve supported agent, platform, provider, policy, integration, GPU, image, and recovery behavior.
- Define deterministic validation and redacted plan output.
- Define migration and removal rules for overlapping menus, flags, and configuration environment variables.
- Measure and remove duplicate parsing, prompting, precedence, conflict, validation, and test machinery.
- Keep resume checkpoints as internal execution state rather than user-authored configuration.

### Excluded

- Child-issue decomposition. We will do that after this epic receives an accepted design decision.
- New agents, providers, platforms, policies, or integrations.
- Secrets stored directly in the configuration file.
- General-purpose templating, inheritance, or arbitrary scripting.
- Compatibility overrides mixed with `--config`.
- A second onboarding engine.

### Constraints

- `--config` must be authoritative. NemoClaw must reject overlapping configuration overrides.
- The migration must preserve fail-closed security and recovery behavior.
- The final implementation must produce a net reduction in the onboarding configuration code footprint.
- The epic must define a removal target and compatibility end state before implementation starts.

## Ongoing Ownership

Proposed owner: NemoClaw CLI and onboarding maintainers.

The accepted decision must name one accountable maintainer for the schema, migration, compatibility policy, and release validation.

## Placement and Support Expectations

Requested placement: core NemoClaw.

This file becomes the supported public contract for install and onboarding desired state. Maintainers own schema evolution, compatibility, security review, documentation, and validation across supported agents and platforms.

**Proposed product decision: Accept.**

Reason: one declarative contract preserves onboarding capability while reducing user choices, precedence rules, and duplicate implementation paths.

This issue is not accepted scope until a maintainer records the final decision and accountable owner.

## Validation Plan

- Validate the schema without host mutation.
- Produce a stable, redacted resolved plan for supported configurations.
- Reject unknown fields and incompatible combinations before downloads or mutation.
- Verify that credential values never enter the config, plan, logs, events, arguments, or persisted non-secret state.
- Prove equivalent supported outcomes for representative OpenClaw, Hermes, Deep Agents, and qualified platform paths.
- Verify failure, resume, rebuild, cleanup, and uninstall behavior from persisted configuration provenance.
- Measure removed public inputs, parsing branches, precedence rules, conflict checks, and tests.
- Require a net reduction in production onboarding configuration code after migration completes.
- Update command reference, quickstarts, security guidance, and migration guidance.
- Use local tests for schema, planning, and compatibility logic. Use live E2E only for real host, runtime, GPU, or external-service boundaries.

## Compatibility Requirements

Preserve the capabilities that the maintained release supports for:

- OpenClaw, Hermes, and LangChain Deep Agents Code.
- Supported Linux, macOS, WSL, DGX, and container-runtime paths.
- Hosted, compatible, local, routed, and managed inference.
- Current policy, messaging, web search, GPU, mount, observability, and custom-image choices.

The design must define schema-version handling, release compatibility, migration diagnostics, and the date or release that removes each legacy input path.

## Security or Privacy Impact

The configuration file is non-secret and may be persisted or reviewed.

Credential entries name a resolver and identifier. Providers receive credentials through the existing trusted host-side boundary. Credential values must not appear in the file, process arguments, plans, logs, events, checkpoints, or status output.

Validation must preserve URL checks, SSRF controls, policy requirements, image identity checks, filesystem restrictions, and fail-closed behavior before mutation.

## Implementation Idea

Use one pipeline:

```text
versioned config + detected host facts + resolved secret references
|
v
validated redacted plan
|
v
reconciliation
```

Any temporary wizard or legacy adapter compiles to the versioned configuration before validation. No adapter may bypass the shared pipeline.

Related work:

- #6401 established the CLI, flags, and environment variables as the current public automation contract.
- #6404 completed stable automation inputs and explicitly deferred a universal configuration framework.
- This epic proposes replacing that contract because the accumulated input surface now creates product and implementation complexity.
- #8379 established serving profiles for managed inference. Profiles should become references inside the complete configuration, not a competing onboarding interface.

## Category

Feature

## Checklist

- [x] I searched existing issues and found no duplicate.
- [x] I described the problem and desired behavior.