Bug Description

When a cron job fires and the primary model (e.g., anthropic/claude-sonnet-4-6) is temporarily unavailable, OpenClaw correctly falls back through the model chain. However, the fallback model gets permanently cached in the session's model field in agents/<agent>/sessions/sessions.json.

On subsequent cron runs — even after the primary model is available again — the session uses the cached fallback model instead of the model configured in the cron job's payload.model field.

Steps to Reproduce

1. Create a cron job with payload.model: anthropic/claude-sonnet-4-6
2. Wait for a run where Anthropic is unavailable and the fallback chain kicks in (e.g., to openai-codex/gpt-5.4-mini)
3. Observe that sessions.json now has "model": "gpt-5.4-mini" for that cron's session key
4. On the next run, even with Anthropic back online, the cron continues using gpt-5.4-mini

Expected Behavior

Cron jobs should always use the model specified in their payload.model configuration, regardless of what model was cached from a previous run's fallback.

Actual Behavior

The cached fallback model in sessions.json takes precedence over the cron's configured model permanently.

Impact

• Jobs silently run on wrong models (potentially consuming paid API credits instead of flat-rate Anthropic)
• Compounds over time — each Anthropic outage infects more session keys
• No self-healing mechanism — requires manual cleanup of sessions.json

Workaround

Periodically clear the model field from cron session keys in sessions.json:

# Clear cached model from all cron session keys
for key, val in data.items():
    if ':cron:' in key and 'model' in val:
        del val['model']

Environment

• OpenClaw: 2026.4.2
• Model chain: anthropic/claude-opus-4-6 → anthropic/claude-sonnet-4-6 → openai-codex/gpt-5.4-mini → openrouter/google/gemini-3-flash-preview