Include active TopicSubscriptions in bulk email reminder recipients

Follow-up to #2070 (introduces the TopicSubscription model).

Goal

Surface people subscribed to upcoming trainings as candidate recipients on an event's bulk email reminder page (EventsController#preview_reminder → app/views/events/_reminder_recipients.html.erb, ReminderRecipientFilter), alongside the event's actual registrants.

Inclusion rule

For a given (facilitator-training) event's reminder list, add each active TopicSubscription (unsubscribed_at IS NULL) with topic: "trainings" where:

• interested_event_id == <this event> → include only on that event's reminder list, or
• interested_event_id is null (general) → include on all training event reminder lists.

Notes / open questions

• Scope of "all lists": general (null-event) training subscriptions should feed facilitator_training events' reminder lists, not every event. Confirm.
• De-dupe: a person may already be an actual registrant of the event and also have an active subscription — show them once, don't send twice. Prefer the real registration row.
• Rendering: reminder recipients are currently EventRegistration rows. Subscription rows have none of that — decide how they appear (a distinct "Subscribed" pill/section, which filters apply, and which email is used — person.preferred_email).
• Consent: only email subscribers who also have mailing_list_consent. Confirm.
• On send, consider recording that a subscriber was contacted (optional).

Blocked on #2070 merging (or can build on that branch).

Start with #2070, then read EventsController#preview_reminder, app/views/events/_reminder_recipients.html.erb, and ReminderRecipientFilter to understand the current EventRegistration flow. Resolve the listed scope, de-duplication, rendering, filter, and consent questions before implementation. Done means eligible active training subscriptions appear once with registrants on the appropriate reminder lists.