fix(timelock): show operation ID in scheduled alerts, escape stale alert label

[spalen0]

Follow-ups to #409, found by a code review of that PR.

Changes

• Scheduled alert shows the operation ID. TimelockController and Compound alerts (and unknown types) now have 🆔 Operation ID: \0x…`in the header, in the same format as the stale-operation alert. This lets you match a stale alert to the original scheduling alert and copy the ID intogetTimestamp/cancel. The line is in the header, so it survives when long call lists are truncated, and a batch shows it once. Aave, Lido and Maple keep their own 🆔 Proposal:/🆔 Vote:lines. An event with nooperationId` gets no line, instead of an empty code span.
• Stale alert escapes the timelock label. format_operation put operation.timelock.label into Markdown V1 unescaped. A _, *, ` or [ in a config label would make Telegram reject the message and fall back to plain text. It now uses escape_markdown, as timelock_alerts.py already does.
• Docs. monitoring.yaml cards (Timelock Events, Stale Ready Operations) and the timelock README now mention the operation ID, as AGENTS.md requires.

Testing

• New tests: ID shown before calls, once per batch, kept under truncation, shown for Compound/unknown types, absent for Aave/Lido/Maple, no empty code span when the ID is missing; label escaping in the stale alert. 6 of them fail without the code changes.
• uv run pytest -q tests/test_timelock_alerts.py tests/test_timelock_stale_operations.py tests/test_monitoring_config.py: 49 passed.
• prek run --all-files (ruff check, ruff format, ty) passes.
• Full suite: 4 failures in tests/test_safe_main.py::TestSafeApiQuota. They fail the same way on main and are unrelated to this change.

🤖 Generated with Claude Code