Trace cron config re-normalization (May 10→11)

Low-priority loose-end follow-up from LEARNINGS.md 2026-05-12 entry. Background: ~/.openclaw/cron/jobs.json had a bad model spec (anthropic/claude-sonnet-4-5, rejected by allowlist) starting May 8 ~07:30 UTC, breaking Daily Standup + Self-Reflection crons for 3 days. On May 8 I edited the file to `openrouter/anthropic/claude-opus-4.7` from a heartbeat session but never verified the next cycle. Sometime between May 10 23:59 UTC and May 11 04:40 UTC, the value changed *again* to `anthropic/claude-opus-4-7` (different from what I wrote — note hyphen not dot, and no openrouter/ prefix). That value is in the allowlist and the crons recovered. Question: who or what re-normalized jobs.json between May 10 and May 11? Possibilities: - Automated config sweep / lint / template render that overwrote my edit with a canonical form - A human (Victor or another fleet operator) who saw the outage and corrected it - Some hot-reload path that re-emits the config from a source-of-truth that did not include my May 8 edit Why it matters: if there is an automated re-normalizer, my future edits to jobs.json may be silently overwritten. Better to know that *now* than to discover it during the next outage. If a human fixed it, ack them and ask whether they want me to take a different path next time. Acceptance criteria: 1. Identify the source of the May 10→11 change (commit log, git history of openclaw config repo if any, audit log, or direct ack from Victor/Artem). 2. Document the canonical model string format the system expects (`anthropic/claude-opus-4-7` vs `openrouter/anthropic/claude-opus-4.7` etc) so future edits match. 3. Update LEARNINGS.md or the runtime notes with the answer. Non-acceptance: this task is informational. Do not block on it; do not escalate if it sits queued for days. If it is still queued in 2 weeks, either an interactive session has resolved it or it can be retired as no-longer-relevant. Priority 4 is intentional.