Make runner updates intuitive and deterministic

[mostlydev]

Problem

Runner base updates are currently not intuitive.

Today, Clawdapus publishes and pins runtime infra images (cllama, claw-api, clawdash, claw-wall, hermes-base) through the claw pull surface, but openclaw:latest and the other local runner tags are still synthetic local base aliases resolved through BaseImageProvider.

That creates a broken operator expectation:

• claw pull sounds like it should fetch the latest runnable platform bits
• claw up sounds like it should be able to remediate stale runner state
• claw build does rebuild service images, but it does not clearly mean "refresh my runner base"
• local tags like openclaw:latest can go stale indefinitely and are not pullable from a registry

This already caused real confusion on the trading pod when trying to move to a newer OpenClaw release.

Goal

Define an intuitive, deterministic runner update UX that answers:

1. How does an operator get the latest supported OpenClaw/Hermes/etc.?
2. Which command owns freshness versus local pod compilation?
3. How do released claw binaries pin and reproduce runner bases?
4. How do we avoid claw up silently changing runner versions on a live pod?

Deliverables

• ADR for runner base image lifecycle and CLI ownership
• implementation plan covering CLI surface, manifest/pinning, migration, docs, and tests
• follow-up implementation issue(s)

Constraints

• The UX should stay aligned with the four-verb surface where possible.
• claw up should remain fail-closed by default; no surprise live upgrades.
• Operators should not need raw Docker commands to refresh runner bases.
• Build-time versus runtime ownership must be obvious from the command model.

Likely design space

At minimum evaluate:

• published + pinned runner base images fetched by claw pull
• explicit runner-refresh command(s) if bases remain synthetic/local
• whether claw up --fix may remediate missing-but-not-stale runners, while leaving version upgrades to explicit commands
• how FROM openclaw:latest and similar scaffold defaults migrate

[mostlydev]

Reworked the draft ADR/plan direction based on the trust model concern.

Revised shape:

• do not make built-in runners default to Clawdapus-published pinned harness images
• keep openclaw:latest and similar tags as Clawdapus-managed local aliases
• add an explicit claw runners update command that rebuilds those aliases from clean upstream sources (--pull --no-cache semantics, rerunning the official install/source path baked into the driver recipe)
• keep claw pull scoped to pinned runtime infra and registry-backed pod images
• keep claw build as pod image compilation, but make it hint explicitly that claw runners update is the way to refresh upstream runner bits first
• teach claw up to detect pod images that are stale relative to the current local runner alias generation via provenance labels

Draft docs updated locally:

• docs/decisions/023-runner-base-image-lifecycle-and-update-surface.md
• docs/plans/2026-04-09-128-runner-update-surface.md