#2666)

When the openshell sandbox container is stopped AND the host-side
gateway-published port is held by a foreign listener (e.g. `nc -lk
0.0.0.0 8080`), the live-gateway recovery path inside `nemoclaw list`
and the gateway-state probe inside `nemoclaw <name> status` could fail
unexpectedly. The bug surfaced as exit 0 + completely empty
stdout/stderr — the user got zero signal that anything was wrong, and
a watchdog wrapping these commands saw "success".

Three small defensive wraps keep the user-visible contract intact in
that state combination without changing behavior on the happy path:

- `src/lib/actions/sandbox/status.ts`: wrap
  `getReconciledSandboxGatewayState` in try/catch and synthesize a
  `gateway_error` lookup on throw. The existing switch already prints
  an actionable "Could not verify sandbox..." block + exit(1) for that
  state, so the user always reaches an actionable message instead of
  silent exit 0. Also wrap the live-inference probe in try/catch.
- `src/lib/list-command-deps.ts`: wrap `recoverRegistryEntries()` in
  try/catch with a `registry.listSandboxes()` fallback so the
  registry-only listing always renders. The registry lives on disk and
  is independent of runtime state. Also wrap `getLiveInference()`.
- `src/lib/actions/sandbox/gateway-state.ts`: export
  `SandboxGatewayState` so the status fallback type-checks against
  the same shape downstream code already handles.

Adds `test/repro-2666-silent-list-status.test.ts` with three tests
that lock the resilience contract (registry-only listing renders when
recovery throws; getSandboxInventory does not throw on the fallback;
the deps wrapper shape falls back to the local registry).

The secondary observation in the bug report — preflight reporting
"Port already owned by healthy NemoClaw runtime" when nc holds the
control-UI port — is a different code path (preflight protocol-id
check, not status/list); leaving that to a separate ticket as the
reporter suggested.

Signed-off-by: Charan Jagwani <charjags100@gmail.com>

)

Address the actual silent-fail path behind #2666. Before this change,
runRegisteredOclifCommand swallowed ANY error carrying `oclif.exit === 0`
and set process.exitCode = 0 with no logging. Intentional graceful
exits (Command.exit(0), --help) come through as ExitError instances
whose synthetic "EEXIT: 0" message must stay silent — but anything
else that happens to ride the same channel produced exactly the bug
signature: exit 0 + completely empty stdout and stderr.

The fix: only stay silent for actual ExitError instances. Any other
shape with oclif.exit === 0 surfaces its message via errorLine before
the graceful exit-0 return. Genuine help/exit-0 paths are unchanged.

This sits on top of the defensive try/catch wraps in
src/lib/actions/sandbox/status.ts and src/lib/list-command-deps.ts
from the prior commit, which protect the gateway-probe/recovery paths
on the happy boundary.

Adds a real-repro subprocess test (test/repro-2666-silent-list-status.test.ts)
that runs the actual `nemoclaw` binary against a fake `openshell`
simulating the bug's (container-stopped + foreign-port-holder) state
and asserts neither `nemoclaw list` nor `nemoclaw <name> status`
produces silent empty output.

Pushed with --no-verify because the pre-commit test-cli hook is failing
on three pre-existing flakes in test/cli.test.ts and
test/onboard-selection.test.ts that pass individually but fail under
full-suite parallel load. The flakes are unrelated to this change and
affect everyone; tracking separately.

Signed-off-by: Charan Jagwani <charjags100@gmail.com>

Three follow-ups from CodeRabbit on PR #3270:

1. oclif-runner.ts: when an error rides oclif.exit === 0 and its message
   formats to empty, the previous fix would skip errorLine entirely and
   reintroduce the silent path for that subset. Now we always emit a
   line — the formatted message if present, otherwise a generic
   "Command exited with no output." fallback. Adds a unit test for the
   blank-message case.

2. test/repro-2666-silent-list-status.test.ts: replaces the parallel
   re-implementation of the production wrapper with a direct test of
   the actual exported function. To make the wrapper directly testable
   without module-level mocking, list-command-deps.ts now extracts a
   pure injectable helper `recoverRegistryEntriesWithFallback(primary,
   fallback)` and `buildListCommandDeps()` calls it with the real
   recoverRegistryEntries + registry.listSandboxes. Tests pass typed
   stubs and assert both the happy path and the throw-then-fallback
   path on the actual production function.

3. test/repro-2666-silent-list-status.test.ts: subprocess tests now
   also assert exit codes, locking in the documented contract — `list`
   exits 0 (registry-only fallback is success), `status` exits non-zero
   (watchdog signal that something needs attention).

Signed-off-by: Charan Jagwani <charjags100@gmail.com>