Resolve legacy blueprint sandbox image pin and OpenClaw version floor

## Problem
`nemoclaw-blueprint/blueprint.yaml` still carries `components.sandbox.image` pointing at `ghcr.io/nvidia/openshell-community/sandboxes/openclaw@sha256:b3d832...`. That digest and `:latest` currently run OpenClaw 2026.3.11, while normal NemoClaw onboarding builds from `ghcr.io/nvidia/nemoclaw/sandbox-base` and the runtime target is declared by Dockerfile `OPENCLAW_VERSION`.

This creates confusion around `min_openclaw_version`: direct blueprint consumers need it to reflect the pinned community image floor, while NemoClaw release/runtime upgrades are controlled by the Dockerfiles.

## Why It Matters
- Code review tools and humans can interpret `min_openclaw_version` as the runtime pin.
- The direct blueprint image can drift away from the NemoClaw runtime path.
- We currently have two image/version contracts in one manifest.

## Proposed Follow-Up
Pick one of these designs and make it explicit:

1. Retire `components.sandbox.image` from the NemoClaw blueprint if the direct blueprint runner path is no longer supported.
2. Replace it with a NemoClaw-owned versioned image/digest and automate digest updates in the base-image release workflow.
3. Split the schema into explicit fields, for example `direct_blueprint_sandbox_image` and `runtime_openclaw_version`, so compatibility floor and runtime target cannot be confused.

## Acceptance Criteria
- The blueprint no longer implies the legacy `openshell-community` image is the NemoClaw runtime pin.
- Release/runtime OpenClaw upgrades have a single source of truth.
- CI blocks any future stale image/version mismatch or requires an explicit follow-up.