test: guard alert protocol keys against unmatched values

[spalen0]

Follow-up to #356, from the review suggestion: "ask AI to write a CI test to trigger an error for any alert that is missing a protocol tag."

The bug was a wrong key, not a missing one

A "missing tag" test would have passed on #356's bug. alert_events.protocol is NOT NULL and send_telegram_message requires the argument, so an untagged alert can't exist. The timelock alerts were tagged YEARN_TIMELOCK, CAP, 3JANE — real values that matched no key the website queries, so they were invisible on https://curation.yearn.fi/monitoring/ for months.

So these tests check the opposite: that every key an alert can be stored under is one a page can display.

What's here

utils/alert_protocols.py declares the displayable keys: a monitoring.yaml slug, one of the two slug→key overrides the frontend applies (compound → comp, rtoken → ethplus), or a key in an explicit page-less allowlist (pegs, origin, lrt, the per-asset peg monitors, YEARN_TIMELOCK_INTERNAL, automation), each with a comment saying why.

tests/test_alert_protocol_keys.py asserts:

• every module-level PROTOCOL = "..." under protocols/ and utils/ (AST scan, ~36 found) resolves to a displayable key;
• every timelock routing key does too;
• process_events really stores them that way — this is the end-to-end one. Removing origin_protocol= reproduces the original bug and fails with {'CAP': 'CAP', 'RTOKEN': 'RTOKEN', ..., 'YEARN_TIMELOCK': 'YEARN_TIMELOCK'};
• YEARN_TIMELOCK → yearn specifically, pinning the reported bug;
• the registry stays honest: no stale override slugs, no allowlisted key that actually has a page;
• the AST scan finds >20 monitors, so a silently broken scan can't make the suite pass vacuously.

Also carries the LRT comment change discussed on #356: the LRT → pegs mapping pointed at nothing (the LRT Pegs page has no alert key, because its scripts emit pegs, origin and lombard), so LRT now stores as lrt, allowlisted as page-less.

Known limits

• The registry duplicates frontend knowledge. SLUG_TO_ALERT_PROTOCOL in risk-score/src/data/monitoring.ts is the real source of truth, so the two can drift. The sturdier fix is an alert_protocol: field in monitoring.yaml, exposed via GET /v1/monitoring, with the frontend reading it instead of hardcoding — worth a follow-up issue.
• Only static keys are covered. Keys passed inline (utils/pegged_assets.py, the Safe monitor's per-multisig routing) aren't scanned. A daily ops check querying the API for distinct protocols and alerting on unknown keys would close that gap.

Testing

• pytest: 961 passed, 4 skipped
• ruff format / ruff check: clean
• mypy utils/alert_protocols.py: clean (repo-wide mypy has pre-existing failures)

🤖 Generated with Claude Code