Notifications - email rules in the admin area #482

Context

PRD §8.6, §14.2. The client asked for email rules as a first-class admin concept, not a hardcoded switch. The reason it is right: the publish flow must ask "should publishing this page notify anyone, and with what words?" before rendering the button. If that answer is a switch in C#, then scoping notifications to /guidance, or turning them off for a fortnight during an incident, is a deployment. As a row it is an admin action with an audit trail.

Scope

• NotificationRule + migration: trigger, path-prefix or list scope, template key, audience, SuppressOnMinorEdit, enabled.
• Admin CRUD where each row renders as one English sentence — "When a page under guidance is published and the editor chose to notify, email everyone watching that page using the Page change template." — because the requirement is that a non-developer can read and audit it.
• The publish path reads rules instead of branching.
• Guard rails, because data-driven means data can be wrong: a rule pointing at a missing or unpublished template renders disabled with a red tag and an explanation and is skipped at publish time; disabling every PagePublished rule removes the notify button from every page editor, because the UI must not offer what the rules forbid.
• Delete behind <govuk-confirm-modal destructive="true"> — quick, in-row, genuinely destructive, which is what that component was built for. Every create / edit / enable / disable / delete writes an AuditEntry.

Acceptance criteria

• AC-R3 A rule whose template has no published version renders disabled with an explanation and is skipped at publish; the page editor shows Publish draft only.
• AC-R4 With every PagePublished rule disabled, no page editor renders a notify button.
• Rule CRUD writes an audit entry per mutation.

Dependencies

Issues 6, 7, 8.

Effort

2–3 days.

Part of #434.