Fix OpenClaw wake behavior for pod-origin externally scheduled invocations

[mostlydev]

Problem

OpenClaw pod-origin invocations scheduled through claw-api still fail in live desks even after the cron store path/schema fix from #132.

The current implementation assumes this contract:

• Clawdapus writes pod-origin OpenClaw jobs into config/cron/jobs.json
• those jobs are compiled with enabled: false
• claw-api wakes them with openclaw cron run <id>
• claw-api treats the wake as a blocking command with a 30s timeout

Live evidence shows two integration problems:

1. OpenClaw rejects cron run <id> for pod-origin jobs in the state Clawdapus currently compiles, returning unknown cron job id.
2. Once a job is made runnable, OpenClaw startup/turn execution can exceed the scheduler's fixed 30s exec timeout, causing the scheduler to record a wake failure even when the runner is still working.

Why this is Clawdapus work

This is not just an OpenClaw core issue. The break is in the Clawdapus/OpenClaw driver + scheduler contract. We picked a Pattern-B wake design (disabled registration + cron run) without locking it against real runner behavior, and we hard-coded a blocking wake timeout that is too aggressive for OpenClaw.

Scope

1. Fix the OpenClaw wake path for pod-origin externally scheduled invocations.
2. Preserve claw-api as the timing authority for pod-origin x-claw.invoke.
3. Add regression coverage that proves a pod-origin OpenClaw invocation can be fired successfully after claw up.
4. Revisit scheduler timeout semantics for OpenClaw wakes so slow startup does not look like a failed fire.

Likely approach

• Move OpenClaw pod-origin wakes away from the current enabled: false + openclaw cron run <id> assumption.
• Prefer a direct wake path through openclaw agent ... if that keeps scheduler ownership intact and supports the needed routing flags.
• Make wake timeout behavior adapter-aware or otherwise stop treating a long-running OpenClaw startup as an immediate failure.

Likely files

• cmd/claw/schedule_manifest.go
• cmd/claw/schedule_manifest_test.go
• cmd/claw-api/scheduler.go
• internal/driver/openclaw/jobs.go
• internal/driver/openclaw/jobs_test.go
• cmd/claw/spike_test.go

Verification

• go test ./internal/driver/openclaw ./cmd/claw ./cmd/claw-api
• spike or live-style coverage that proves an OpenClaw pod-origin wake succeeds and does not degrade the schedule due to an artificial timeout

[mostlydev]

Confirmed root cause from live Tiverton/OpenClaw inspection:

• Current Clawdapus OpenClaw materialization writes jobs.json under the config directory.
• Current OpenClaw builds resolve cron definitions from ~/.openclaw/cron/jobs.json (the installed docs and bundle code both point there).
• In the failing live pod, openclaw cron list --json returned an empty job set even though Clawdapus had generated jobs, which explains the repeated unknown cron job id wake failures.

This branch fixes the driver to mount the dedicated native cron directory and write jobs.json there, while keeping pod-origin wakes on the documented openclaw cron run <id> contract. Broader liveness / restart hardening is still separate follow-up work.