fix(hooks): validate event_name against the canonical event set

[gmoncor]

What

Duplicate the CANONICAL_EVENTS set from adapters/profile.py into the stdlib-only hook script and its events.py twin, and emit a non-blocking warning when event_name falls outside that set.

Why

Profile-parse time already enforces this whitelist before a hook is ever registered; this closes the defense-in-depth gap with a drift-detection warning, matching the existing never-fail treatment used for hooks.relay-stale.

How

• Duplicate CANONICAL_EVENTS inline in bmad_loop_hook.py and events.py (twin pattern, both stdlib-only, cannot import each other).
• When event_name is outside the set, still write the event exactly as today, but also emit a non-blocking warning (stderr, never stdout).
• Add a parity/ablation test in tests/test_hook_script.py and tests/test_events.py.

Testing

Ran tests/test_hook_script.py and tests/test_events.py (45 passed, 9 skipped platform-specific); confirmed the twin-source parity check still passes with the duplicated set in both files.

Changelog

Added: the hook script now warns (non-blocking) if it receives an event name outside the canonical set, without ever dropping the signal.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gmoncor]

Closing: adapters/profile.py already rejects non-canonical event names before a hook is ever registered, so the warning this adds fires only for a hand-edited hook config or a profile that already skipped that validation — speculative hardening rather than an observed problem. It also claims the twin-source parity test (test_the_twinned_source_is_identical) covers the new duplicated CANONICAL_EVENTS constant; I verified it does not (the name isn't in the TWINNED tuple), so that guarantee wasn't real. Not worth a maintainer's time as-is.