Add an awaitable messaging-readiness contract after rebuild #7383

Problem

A successful nemoclaw <sandbox> rebuild can return before a newly configured
messaging channel is operational.

On a fresh Brev deployment, an existing OpenClaw coordinator was enrolled with
Slack and rebuilt successfully. Immediately after the rebuild returned:

• NemoClaw reported the Slack channel as registered;
• the OpenClaw Slack account was configured;
• but Socket Mode was not connected yet and the account's live probe was not
  ready.

No corrective configuration was required. The same runtime became healthy
during subsequent bounded polling.

This leaves non-interactive callers without a supported way to distinguish:

1. successful rebuild with expected deferred channel initialization;
2. a channel that is still converging;
3. a terminal credential, policy, network, or plugin failure.

Environment

• NemoClaw: 0.0.81 (457311c60ff3a00ccbf2dd208d6cade5736d0fc7)
• OpenShell: 0.0.72
• Node.js: 22.23.1
• Platform: Brev / Ubuntu, Docker driver
• Channel: Slack using Socket Mode
• Flow: add/register Slack on an existing OpenClaw sandbox, then rebuild

No credential values or Slack identifiers are included in this report.

Reproduction shape

1. Start with a healthy OpenClaw sandbox that does not yet contain the Slack
   package/configuration.
2. Register Slack through the supported host-side channel flow.
3. Run the required sandbox rebuild and wait for it to return success.
4. Immediately inspect both:
   • nemoclaw <sandbox> channels status --channel slack --json
   • openclaw channels status --probe --json through
     nemoclaw <sandbox> exec
5. Observe a transient interval where registration/configuration exists but the
   account is not yet running, connected, and probe-ready.
6. Poll again without changing configuration; the account eventually becomes
   connected and probe-ready.

The automation that found this originally performed only one immediate
post-rebuild check and therefore reported a false installation failure. Its
current workaround polls registration plus the live OpenClaw channel probe
every five seconds for up to 180 seconds.

Expected contract

NemoClaw should expose an awaitable, machine-readable messaging readiness
boundary. Any of these shapes would address the gap:

• nemoclaw <sandbox> rebuild --wait-ready [--timeout <seconds>]
• nemoclaw <sandbox> channels status --channel <name> --wait [--timeout <seconds>] --json
• a stable lifecycle event/result API that callers can await after rebuild

The contract should report, without exposing credentials:

• desired/registered configuration;
• runtime process started;
• transport connected where applicable;
• channel-specific account or credential probe result;
• policy coverage;
• terminal versus retryable failure;
• elapsed time or last transition timestamp.

A timeout or terminal failure should return nonzero with a structured reason.
Success should mean that the channel is operational according to its
adapter-specific readiness definition, not merely that the sandbox or gateway
port is up.

Impact

• Automation reports false install failures after successful rebuilds.
• Callers must duplicate channel-specific polling and parse OpenClaw internals.
• Immediate retries can trigger unnecessary or disruptive rebuild/configuration
  work.
• Operators cannot reliably distinguish eventual readiness from a permanently
  broken channel.

Related issues

These are adjacent but do not own this contract:

• fix(e2e): messaging-compatible-endpoint C8 timeout due to deferred plugin init #3656 documented deferred plugin initialization and added an E2E health poll,
  but did not add a public CLI readiness boundary.
• [All Platforms][CLI&UX] channels status shows Telegram as all-[ok] while the bridge is unreachable — no runtime health probe for Telegram #6888 added a runtime health probe for Telegram status, but not an awaitable
  post-rebuild contract.
• Epic: stabilize onboarding and runtime lifecycle contracts before public extensibility #6224 tracks broader onboarding/runtime lifecycle contract stabilization.
• [Channels] Channel bot stops responding after channels add <channel> + rebuild (verified on slack; likely affects any messaging channel) #4012 and Slack channel never starts despite config enabled: true, env vars present, and plugin installed #4189 covered permanent Slack failures after channel setup rather
  than successful eventual convergence.

Acceptance criteria

• A non-interactive caller can wait for configured messaging channels to
  reach adapter-defined operational readiness after rebuild.
• The result is machine-readable and secret-safe.
• Expected deferred initialization does not produce a false terminal
  failure.
• Credential, policy, network, plugin, and timeout failures are
  distinguishable.
• Tests cover delayed success and terminal failure for at least Slack Socket
  Mode.
• The contract is designed so other asynchronous messaging adapters can
  implement equivalent readiness semantics.