Give Hermes scheduled wakes a runner-sized timeout

[mostlydev]

Problem

A production Hermes schedule fired manually through claw-api and completed its intended managed-tool action, but claw-api recorded the invocation as wake-error with detail exec timed out.

The audit sequence was:

• claw-api recorded the wake attempt
• the Hermes runner completed two successful inference rounds shortly afterward
• the managed tool action succeeded
• the schedule state remained failed, so the operational record contradicted the actual runner outcome

Current scheduler policy explains the false failure:

• cmd/claw-api/scheduler.go gives openclaw-exec a 2-minute budget
• hermes-exec falls through to the generic 30-second budget
• Hermes cron run <job_id> schedules work through the runner-native cron path, and cold CLI/file-lock/scheduler timing can exceed 30 seconds even when the trigger is accepted and the run succeeds

This can incorrectly increment consecutive failures and degrade/throttle a healthy dormant or manually fired safety invocation.

Scope

1. Give hermes-exec an adapter-specific wake budget that covers the runner-native cron trigger path.
2. Keep the policy in claw-api's adapter-aware scheduler rather than adding downstream wrapper logic or cllama behavior.
3. Add a focused regression test for Hermes timeout selection.
4. Document the change under Unreleased without touching release pins or version metadata.

Proposed change

Use a dedicated Hermes wake timeout of 2 minutes, matching the existing OpenClaw runner-native cron budget while keeping the 30-second default for adapters without evidence that they need more.

Verification

• go test ./cmd/claw-api
• go test ./...
• targeted test proves hermes-exec does not use the generic 30-second budget
• existing default and OpenClaw timeout tests remain explicit

Constraints

• No downstream pod patch.
• No cllama changes; this is runner wake transport accounting.
• No release artifact or image-pin changes.