ux/api: disable scaffolded/deprecated/human status selection until lifecycle semantics are implemented

[moltar-bot]

Problem

Agent status selection currently allows scaffolded, deprecated, and human, but behavior is inconsistent and not fully defined across UI, reconcile, auth, and runtime config paths.

Observed confusion:

• Setting status in UI may appear to not persist or gets overridden by reconcile/runtime-derived state in some flows.
• human is not a first-class runtime mode in the DB model (agents CHECK allows scaffolded|active|deprecated only), requiring internal mapping hacks.
• Users can choose statuses that do not have clearly documented, end-to-end semantics.

Decision (for now)

Temporarily remove/disable user-facing status options:

• scaffolded
• deprecated
• human

Keep only active selectable in AgentEditModal until lifecycle semantics are formally defined and implemented end-to-end.

Why

We should not expose controls that imply behavior we don’t reliably implement.

Scope

• UI: AgentEditModal status select should only allow active (or hide status field entirely for now).
• API: reject unsupported status inputs with 400 (or normalize to active) while feature-flagging future lifecycle modes.
• Docs: note that lifecycle statuses are reserved/not yet supported.

Follow-up design work required

Define explicit lifecycle semantics before re-enabling status controls:

1. Source of truth for status (DB vs runtime-derived)
2. Reconcile interaction rules
3. Auth interaction rules (who is blocked and when)
4. Runtime config implications (whether non-active statuses affect OpenClaw config writes)
5. UI display rules and transitions (who can set/clear, with audit trail)

Once semantics are defined, reintroduce statuses with tests and migration plan.