Fixes #49190.

Problem summary

Cron isolated-agent runs currently collapse final delivery failures into the primary error run status even when the agent execution itself succeeded. That makes notification/channel failures look like execution failures, increments error/backoff state, can mark task records failed, and leaves the Control UI without a first-class status filter for this partial-success case.

Root cause

The isolated delivery dispatcher returned status: "error" for unresolved delivery targets and direct outbound send failures. applyJobResult only distinguished ok, skipped, and error, so delivery-only failures used the same scheduler path as model/tool/runtime failures.

Architectural reasoning

This keeps the change additive and follows the existing cron contract surface:

• Adds warning to the cron run status union, gateway validation schema, run-log filters, plugin hook type, CLI/UI mirrors, and QA helper wait logic.
• Leaves real agent/runtime failures as error; finalizeCronRun only asks delivery dispatch to downgrade delivery failures to warning when the agent payload did not already indicate a fatal execution failure.
• Keeps delivery diagnostics in the delivery-specific fields: warning runs set delivered: false, persist lastDeliveryStatus: "not-delivered", and keep lastDeliveryError.
• Keeps scheduler behavior aligned with partial success: warning runs reset execution-error counters, do not trigger error backoff/failure alerts, complete task-ledger records as successful execution, and terminal one-shot warning runs are disabled but not auto-deleted so operators can inspect state.
• Extends Control UI filters/status labels and CLI coloring without changing existing ok, error, or skipped semantics.

Real behavior proof

• Behavior or issue addressed: Cron isolated-agent runs whose agent execution completes but final announce delivery cannot resolve/send now persist as warning instead of error.
• Real environment tested: Windows 11 local OpenClaw source checkout on branch codex/49190-cron-warning-status after rebasing onto upstream/main (6e18c8ec15). Runtime used Node 24.14.0 through node --import tsx; no live Slack credentials or private endpoints were used.
• Exact steps or command run after this patch: Ran a one-off local Node script from the repo root with node --import tsx --input-type=module. The script loaded the real CronService and dispatchCronDelivery modules, created an isolated cron job with Slack announce delivery, simulated the delivery target failure outbound not configured for channel slack, ran the job with cron.run(job.id, "force"), and printed the persisted job state plus dispatcher result.
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Copied terminal output from the local run:

{
  "proof": "cron delivery warning status after patch",
  "manualRunOk": true,
  "jobState": {
    "enabled": false,
    "lastRunStatus": "warning",
    "lastStatus": "warning",
    "consecutiveErrors": 0,
    "lastDelivered": false,
    "lastDeliveryStatus": "not-delivered",
    "lastDeliveryError": "outbound not configured for channel slack"
  },
  "finishedEvent": {
    "status": "warning",
    "delivered": false,
    "deliveryStatus": "not-delivered",
    "deliveryError": "outbound not configured for channel slack"
  },
  "dispatchResult": {
    "status": "warning",
    "errorKind": "delivery-target",
    "delivered": false,
    "deliveryAttempted": false,
    "error": "outbound not configured for channel slack"
  }
}

• Observed result after fix: The cron run completed with manualRunOk: true, persisted lastRunStatus: "warning", kept consecutiveErrors: 0, marked delivery as not-delivered, and returned the dispatcher delivery-target failure as warning with delivered: false.
• What was not tested: No live Slack workspace send was attempted because this proof intentionally used a redacted local setup without channel credentials. Live channel sends remain covered by existing channel runtime paths; this PR only changes the status classification after delivery failure.

Testing performed

• pnpm test src/cron/isolated-agent/delivery-dispatch.double-announce.test.ts src/cron/service.persists-delivered-status.test.ts src/cron/service/timer.regression.test.ts src/gateway/protocol/cron-validators.test.ts ui/src/ui/views/cron.test.ts ui/src/ui/controllers/cron-filters.test.ts src/tasks/task-registry.test.ts
• pnpm test src/cron/service.persists-delivered-status.test.ts src/cron/run-log.test.ts -- -t "persists warning|filters warning"
• pnpm test src/cron/cron-protocol-conformance.test.ts src/cron/cron-protocol-schema.test.ts
• pnpm lint:core
• pnpm lint:scripts
• pnpm lint:extensions
• pnpm lint:ui:no-raw-window-open
• pnpm docs:check-mdx
• pnpm lint:docs -- docs/cli/cron.md docs/automation/cron-jobs.md
• pnpm exec oxfmt --check --threads=1 ...changed files...
• pnpm tsgo:core
• pnpm tsgo:core:test
• pnpm tsgo:test:ui
• pnpm tsgo:extensions
• pnpm tsgo:core (after rebasing onto latest upstream/main, to verify the OpenAI stream type CI repair)
• pnpm tsgo:extensions:test
• pnpm check:madge-import-cycles (after rebasing onto latest upstream/main)
• pnpm test src/cron/run-log.test.ts -- --reporter=dot
• pnpm test src/cron/run-log.test.ts src/cron/service.persists-delivered-status.test.ts src/cron/service/timer.regression.test.ts src/cron/isolated-agent/delivery-dispatch.double-announce.test.ts src/gateway/protocol/cron-validators.test.ts ui/src/ui/controllers/cron-filters.test.ts ui/src/ui/views/cron.test.ts src/agents/openai-transport-stream.test.ts -- --reporter=dot
• pnpm exec oxfmt --check --threads=1 src/cron/run-log.ts src/agents/openai-transport-stream.ts- pnpm ui:i18n:check (after rebasing onto latest upstream/main; local Windows run reached translation subprocess spawn EINVAL after raw-copy baseline passed)
• pnpm check:changed
• git diff --check

Local note: the full pnpm test src/cron/run-log.test.ts -- --reporter=dot initially reproduced a Windows append-path failure from appendRegularFile (Refusing to append after file changed). I fixed the run-log writer to keep the symlink-parent guard while appending through the fs-safe root writer, then reran pnpm test src/cron/run-log.test.ts -- --reporter=dot and the grouped cron/OpenAI targeted command successfully. Also, ui:i18n:sync initially failed because the configured translation subprocess could not spawn in this Windows shell; I reran the repo sync/check path with translation keys falling back to English for the new cron.runs.runStatusWarning key, which updated the locale metadata fallback keys and passed control-ui-i18n check.

Risk analysis

Risk is medium-low. The protocol change is additive, existing statuses keep their behavior, and the scheduler continues to apply error retry/backoff only to error. The main compatibility surface is clients that exhaustively switch on cron run statuses; this PR updates repo-owned TS/UI/plugin helper surfaces and leaves generated Swift/openclaw-kit fields as AnyCodable/string-compatible where applicable.

Backward compatibility

Existing stored ok, error, and skipped run records remain valid. New warning records are accepted by the gateway schema, CLI/UI type mirrors, run-log filters, and plugin hooks. Older external clients that do not know warning will see a new string status but can still inspect deliveryStatus/deliveryError for details.

Screenshots/logs

No screenshots; this is a scheduler/protocol/UI-state change. Relevant command logs are summarized above.