Improve managed-service liveness handling for OpenClaw startup stalls and freezes

[mostlydev]

Problem

Live desks can leave an OpenClaw container stuck in a bad state where the process remains up, Docker does not restart it, and scheduled invocations begin accumulating failures.

Current failure chain:

• OpenClaw startup can be slow enough that the scheduler reaches it before the runner is actually healthy.
• claw-api currently treats wake execution as an immediate blocking action and records wake failures when the target is not yet healthy.
• The OpenClaw driver's compose healthcheck and claw health probe shell into openclaw health --json, but a persistently unhealthy gateway does not automatically exit the container, so Docker restart policy never fires.
• PostApply only checks that the container is running, not that the gateway has actually become healthy.

Scope

1. Make claw-api health-aware before waking a managed service so startup lag does not count as a schedule failure.
2. Improve OpenClaw startup verification so claw up -d waits for real liveness, not just a running PID.
3. Add a liveness mechanism that turns persistent OpenClaw health failure into container exit so Docker restart policy can recover the service.
4. Clarify ownership of runner-native cron state so agents do not treat OpenClaw-native cron as durable infrastructure state.

Likely files

• cmd/claw-api/scheduler.go
• cmd/claw-api/main.go or adjacent runtime loop code
• internal/driver/openclaw/driver.go
• internal/driver/openclaw/baseimage.go
• internal/driver/shared/clawdapus_md.go

Verification

• targeted Go tests for scheduler health-gating and OpenClaw post-apply/health behavior
• integration/spike coverage showing startup lag is skipped rather than counted as failure
• verification that a persistently unhealthy OpenClaw gateway causes container restart under the existing restart policy

[mostlydev]

Confirmed live follow-up after the cron-store repair:

• unknown cron job id is gone once the native store is normalized.
• The remaining scheduler failures are wake-error with detail exec timed out.
• The current claw-api scheduler wraps every wake exec in a fixed 30s timeout, even for openclaw-exec.
• This means startup lag or slow openclaw cron run <id> response gets recorded as a schedule failure and contributes to degraded throttling even when the runner is still booting.

Implementation plan for this issue:

1. Make the scheduler adapter-aware for wake timeout policy.
2. Add health-aware deferral for OpenClaw wakes so a target in Docker health starting or unhealthy does not count as a failed schedule fire.
3. Keep broader container-exit/watchdog hardening as follow-up inside this issue unless it naturally falls out of the scheduler work.

[mostlydev]

Draft PR ready: #162

This PR covers the scheduler-side mitigation for the live exec timed out failures:

• OpenClaw-specific wake timeout budget
• health-aware deferral while Docker health is starting or unhealthy

It does not yet add the broader container-exit/watchdog behavior for persistently unhealthy runners.