…VIDIA#3404)

The reactive blueprint bump in main only kicks the can down the road —
the installer would re-trip the compatibility gate on the next OpenShell
release bump. This makes the installer self-correct by querying published
OpenShell releases and pinning the fetch to the highest release ≤ the
blueprint's max_openshell_version. If no compatible release exists, the
install fails with a clear error naming both the published latest and the
configured max.

- Adds a pure resolver (resolveOpenshellInstallVersion) plus boundary-safe
  tag parser (parseOpenshellReleaseTag) to onboard/openshell-install.ts.
- installOpenshell() in onboard.ts lists release tags via gh/curl and
  passes the resolved version through NEMOCLAW_OPENSHELL_PIN_VERSION.
- install-openshell.sh honours that env (validated against ^X.Y.Z$) and
  falls back to the hardcoded pin only when the resolver was unable to
  reach GitHub.
- Unit tests cover the four required cases: latest > max → highest ≤ max;
  latest ≤ max → latest unchanged; no release ≤ max → clear error; max
  missing → no-max fallback. Plus malformed-input boundary cases and the
  QA repro (latest=0.0.38, max=0.0.36 → 0.0.36).

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

)

Addresses CodeRabbit review feedback and the onboard-entrypoint-budget
check on NVIDIA#3446, and widens scope so the shell installer's MIN/MAX
constants are no longer a second source of truth:

- Move installOpenshell() body to src/lib/onboard/openshell-pin.ts so
  src/lib/onboard.ts shrinks by 19 net lines (entrypoint budget passes).
- Paginate published OpenShell release lookups: gh release list uses
  --limit 1000; the curl fallback walks per_page=100&page=N until the
  page is short. Older compatible versions are reachable once
  NVIDIA/OpenShell exceeds one page.
- Skip NEMOCLAW_OPENSHELL_PIN_VERSION (and now MIN/MAX) validation on
  the dev channel — that path installs from RELEASE_TAG=dev and never
  consults PIN_VERSION, so a malformed override should not abort a dev
  install.
- TS pin module overlays NEMOCLAW_OPENSHELL_MIN_VERSION and
  NEMOCLAW_OPENSHELL_MAX_VERSION from the blueprint onto spawn env;
  install-openshell.sh validates each against ^X.Y.Z$ and overrides its
  hardcoded MIN_VERSION / MAX_VERSION when the env is present and the
  channel is stable.
- Unit tests cover the new MIN/MAX/PIN overlay and the orchestrator
  fallback paths (offline, no max, no release ≤ max).

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…NVIDIA#3404)

Address two CodeRabbit major findings on NVIDIA#3446:

- scripts/install-openshell.sh no longer defaults PIN_VERSION to a
  blueprint MAX env override. When the TS resolver couldn't reach
  GitHub it only sets MIN/MAX (never PIN), and the script's hardcoded
  PIN_VERSION is the known-good safe fallback. Letting the blueprint
  MAX silently drive the pin meant a bumped blueprint + rate-limited
  install would probe an unreleased tag.
- src/lib/onboard/openshell-pin.ts paginated curl fetch returns null
  on any per-page failure rather than the partial accumulated list. A
  page-2+ failure can hide older compatible releases, which would
  cause the resolver to falsely return "incompatible" and abort the
  install — null preserves the legacy fallback.

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

NVIDIA#3404)

While running the issue NVIDIA#3404 repro locally with NEMOCLAW_OPENSHELL_PIN_VERSION
set to a malformed value, the script exited 1 with no visible error: the
`apply_blueprint_override` helper called `fail` inside a `$(...)` substitution,
which captured the stderr-less error message into the variable assignment
instead of letting it reach the user.

Inline the regex check at each call site so `fail`'s message reaches stderr
when an override is malformed. Behaviour for valid overrides is unchanged.

Verified end-to-end against the real install-openshell.sh:
- A. issue NVIDIA#3404 repro (resolver picked 0.0.36) → "Installing OpenShell from release 'v0.0.36'..."
- B. today (resolver picked 0.0.39) → "Installing OpenShell from release 'v0.0.39'..."
- C. offline (TS only set MIN/MAX, no PIN) → script keeps hardcoded 'v0.0.39'
- D. dev channel with garbage overrides → "Installing OpenShell from release 'dev'..."
- E. malformed PIN on stable → fails loudly with the env-name in the message

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…VIDIA#3404)

CodeRabbit minor on NVIDIA#3446: the comment introduced in 18fe705 claimed
fail()'s output reaches stderr, but fail() (Line 14-17) still echoed to
stdout. Today the inlined validation avoids $(...) capture, so the user
does see the message, but the stderr claim itself was false.

Redirect fail()'s echo to stderr (>&2) so it matches both the comment
and conventional shell error reporting. The non-error path (info/warn)
is untouched. The validation continues to live outside $(...) so a
future caller cannot accidentally capture it.

Signed-off-by: Dongni Yang <dongniy@nvidia.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

If a host already has an OpenShell release newer than this NemoClaw release supports, reinstall the pinned compatible release instead of hard-failing before the download path.

This lets the NVIDIA#3474 regression guard pass while preserving the post-install blueprint max gate.

Related: NVIDIA#3474