Add a reusable notification system; wire it into news publishing

New `notifications` app: Notification (club-scoped, keyed to the
member it's about, generic `source` via a ContentType/object_id pair
so future activities can reuse this without a new model each time)
plus notify_members(), which resolves each member's own email (if
they hold a login) and every parent/guardian's, always -- a child
with their own account doesn't opt their parents out -- and emails
the club-branded template to whichever addresses that resolves to.
Delivery is email-only for now (no in-app feed exists yet); the row
is created either way, ready for one later.

news.tasks.notify_news_published resolves the audience (a team-scoped
item's current rosters, or every active member if it's club-wide) and
calls notify_members with the item's title/plain-text body.
NewsPublishForm gained a "Notify linked members" checkbox (opt-in,
default off); when checked, NewsPublishView schedules the task with
Celery's `eta` set to the item's own published_at -- a scheduled
item's notification arrives when it actually goes live, and an
immediate publish (eta in the past) just runs right away, no separate
branch needed.

Registered the new notification email on the Club identity page's
Email tab alongside the others.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ECGMEwrc2k4D8VQuwjstj9

management/email_previews.py

@@ -4,10 +4,11 @@ so a club can see exactly what a member/parent receives without anything
 actually being sent.
 
 Each entry renders the *real* templates the real send functions use (see
-club.services.invoicing.send_invoice_email/send_reminder_email, and allauth's
-own password-reset flow via templates/account/email/password_reset_key_message.html)
-against a hand-built sample context -- never a real Member/ClubMembership/
-DuesInvoice row, so this needs nothing from the database beyond the current
+club.services.invoicing.send_invoice_email/send_reminder_email,
+notifications.services.notify_members, and allauth's own password-reset flow
+via templates/account/email/password_reset_key_message.html) against a
+hand-built sample context -- never a real Member/ClubMembership/DuesInvoice/
+Notification row, so this needs nothing from the database beyond the current
 club itself, and can't leak anything real. Adding a new branded email later
 means adding one entry here, not touching the view or template.
 """
@@ -43,6 +44,11 @@ def _dues_invoice_context(club, request, *, overdue):
     return {"club": club, "invoice": invoice, "membership": membership, "member": member, "request": request}
 
 
+def _notification_context(club, request):
+    notification = SimpleNamespace(title="Training moved to Tuesday", body="This week's U16 training moves from Thursday 19:00 to Tuesday 19:00, same location. See you there!")
+    return {"club": club, "notification": notification, "request": request}
+
+
 def _password_reset_context(club, request):
     # Mirrors allauth.account.internal.flows.password_reset.request_password_reset's
     # own context -- current_site is only used by the *stock* .txt template's
@@ -77,6 +83,15 @@ EMAIL_PREVIEWS = [
         html_template="club/email/dues_invoice_reminder.html",
         build_context=lambda club, request: _dues_invoice_context(club, request, overdue=True),
     ),
+    EmailPreview(
+        key="notification",
+        label=_("Member notification"),
+        description=_("Sent to a member (and always their parent/guardian too) when staff notify them about something -- e.g. the “Notify linked members” option when publishing news."),
+        subject_template="notifications/email/notification_subject.txt",
+        text_template="notifications/email/notification.txt",
+        html_template="notifications/email/notification.html",
+        build_context=_notification_context,
+    ),
     EmailPreview(
         key="password_reset",
         label=_("Password reset"),