fix(onboard): prepare managed startup files before strict filesystem enforcement

## Investigation Summary

- An isolated Linux test with the published Hermes image and OpenShell `0.0.116` fails on a missing managed CA file under `hard_requirement`.
- The image also lacks the managed runtime environment file. The supervisor stops at the CA file, so the environment-file failure was not reproduced separately.
- NemoClaw requires the initial held sandbox to reach `Ready` before it prepares the managed bootstrap replacement.
- Managed startup creates these files during later root profile application. This creates a dependency cycle when the initial policy requires them.
- The missing-file rejection is reproduced. The bootstrap-ordering conclusion is source-backed; complete managed onboarding with a fix remains untested.

## Description

Managed onboarding must support strict filesystem enforcement when the effective policy requires NemoClaw-generated startup files.

The relevant paths are:

- `/run/nemoclaw/managed-startup-ca-bundle.pem`
- `/run/nemoclaw/managed-startup-runtime.env`

OpenShell rejects an absent required path before the initial held sandbox reaches `Ready`. NemoClaw cannot then reach the root preparation that creates the files.

Expected behavior: NemoClaw prepares required managed files through its owned bootstrap flow before the supervisor needs them. The agent remains stopped until policy enforcement, startup validation, and identity verification succeed.

Do not resolve this by changing `hard_requirement` to `best_effort`, adding empty placeholder files, or broadening filesystem grants.

## Reproduction Steps

The executed test isolates supervisor filesystem admission; it is not a complete onboarding reproduction.

1. Use the published Hermes image and OpenShell supervisor listed below.
2. Supply filesystem policy entries for the two paths above, with `landlock.compatibility: hard_requirement`.
3. Ensure other policy-required static directories exist. In the diagnostic container, creating `/app` as root-owned mode `0755` cleared an earlier, separate missing-directory error.
4. Run the supervisor in process mode with the policy and `/bin/true` as the workload.
5. Observe exit status `1` before the workload starts.

The diagnostic used an isolated Docker network and did not mount credentials or the Docker socket. It did not create either managed startup file.

## Environment

- Linux, x86_64, Docker, Landlock available.
- OpenShell supervisor: `0.0.116`.
- Installed NemoClaw during the follow-up test: `b8337ce01231264726b028d1147dc2634fd85885`.
- Node.js: `22.23.1`; CLI and plugin builds passed.
- Hermes image: `ghcr.io/nvidia/nemoclaw/hermes-sandbox@sha256:d2b5b154696df8eabd5de5a029505c4e851137dbeffcb33fb610dec238e014e5`.
- Image source revision: `e6068115cc5e02e0d05abdb46ea4509138847617`. Updating the CLI did not update this image.
- Test date: September 12, 2026.

## Debug Output

```text
Landlock path unavailable in hard_requirement mode:
/run/nemoclaw/managed-startup-ca-bundle.pem (path does not exist)
```

This is supervisor diagnostic output, not a `nemoclaw debug` archive.

## Source Evidence

The ordering remains present at reviewed main commit `2d1a495762f67ed07e0a7915bd5df841086ce552`:

- [Initial held-workload creation requires Ready](https://github.com/NVIDIA/NemoClaw/blob/2d1a495762f67ed07e0a7915bd5df841086ce552/src/lib/onboard/managed-bootstrap/docker.ts#L3637).
- [The coordinator prepares the replacement only after held-workload creation](https://github.com/NVIDIA/NemoClaw/blob/2d1a495762f67ed07e0a7915bd5df841086ce552/src/lib/onboard/managed-bootstrap/adapter.ts#L1610).
- [CA generation is conditional on a supplied corporate CA](https://github.com/NVIDIA/NemoClaw/blob/2d1a495762f67ed07e0a7915bd5df841086ce552/src/lib/onboard/managed-startup/image-runtime.ts#L1125).
- [Root profile application writes the runtime environment and authenticated completion record](https://github.com/NVIDIA/NemoClaw/blob/2d1a495762f67ed07e0a7915bd5df841086ce552/src/lib/onboard/managed-startup/image-runtime.ts#L1497).

## Scope and Acceptance Criteria

- Use the existing managed bootstrap and startup contracts. First check whether an existing supported preparation mechanism can satisfy the ordering.
- With valid required inputs, managed Hermes onboarding reaches `Ready` under `hard_requirement` without a manually modified image.
- Generate actual validated CA content and the authenticated runtime environment. Preserve root ownership, read-only access, and completion verification.
- Verify that the generated files remain readable under the effective policy after bootstrap replacement.
- Reject missing required CA input, invalid files, ownership violations, and symlink substitution. Preserve ordinary onboarding without a corporate CA when its policy permits that configuration.
- Do not start the agent or send a successful component activation callback after failed preparation or identity verification.
- Preserve existing bounded failure, interruption, and recovery behavior.
- Add focused ordering and negative tests. Validate the real Linux supervisor boundary with a matching managed image. Check shared OpenClaw behavior for regressions without claiming an OpenClaw reproduction.
- Keep policy ownership and OpenShell enforcement unchanged. A new upstream interface is not established as necessary; record a concrete limitation if existing mechanisms cannot satisfy the requirement.

Out of scope: new component protocols, network preparation, providerless image generation, external service configuration, and unrelated static image-directory fixes.

## Related Issues

- #9360 concerns a missing filesystem policy grant. Here, the policy already names the file, but the file does not exist when enforcement begins.
- #9357 concerns parent-directory permissions after file creation.
- #8454 concerns missing CA material after a sandbox reports `Ready`.

## Checklist

- [x] Reproduced the missing-file rejection and stated the limits of that test.
- [x] Searched existing issues and pull requests; no matching bootstrap-ordering issue found.

Start with src/lib/onboard/managed-bootstrap/docker.ts at initial held-workload creation, then read adapter.ts and image-runtime.ts at the cited preparation and file-writing points. Reproduce the process-mode supervisor failure with hard_requirement before changing the ordering. Done means valid managed files are prepared and verified before enforcement, negative cases remain rejected, and focused ordering tests plus a matching Linux supervisor check pass.

Written by the indexing model from the issue text.