feat: Unified notification preferences center (per-channel, per-event)

[joelpeace48-cell]

Background & current state

With multiple channels (in-app NEW-094, web push NEW-093, email #342), there's no single place for users to control what they receive where. Without a respected preference store, we risk over-notifying.

Goal

Add a unified notification preferences center: per-channel, per-event-type opt-in/out, enforced by the notification service.

Technical design

• Preferences model: (user, event_type, channel) -> enabled. The notification service checks preferences before dispatching on any channel; sensible defaults; "unsubscribe all".
• Frontend preferences UI grouped by event type with channel toggles.

Edge cases

• New event types → safe default + surfaced in UI.
• Legal/critical notices (e.g., security) → non-disableable category.
• Conflicting defaults → documented precedence.

Task breakdown

• Preferences model + enforcement in notification dispatch.
• Preferences UI (event × channel matrix).
• Non-disableable critical category.
• Matrix tests (channel × event respected).

Acceptance criteria

• Disabling a channel/event suppresses delivery on it; critical notices still send.

Testing & verification

• Matrix tests asserting suppression per preference.

Out of scope

• The channels themselves (NEW-093/094, Backend: Add email notification integration for campaign lifecycle events #342).

Dependencies / related

• Central to NEW-093/094, Backend: Add email notification integration for campaign lifecycle events #342.

Difficulty: medium · Effort: M

[Killerjunior]

@Killerjunior has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Hi maintainer, I have read and understood the issue requirements and checked the necessary documentation. I’m confident I can work on this task effectively and deliver a proper solution.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Killerjunior to this issue.

[kulayddon]

@kulayddon has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

This one caught my eye maintainer. I'll implement it carefully, watch for the edge cases, and align with your existing conventions instead of doing it my own way. I keep PRs small and communicate early. Please assign me sir.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @kulayddon to this issue.

[CelestinaBeing]

@CelestinaBeing has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

Good day Maintainer, i wil love to work and own this. I work iteratively, draft first, then refine on review, so you'll see progress early and can course-correct fast. The change will be focused and well-tested. Please assign me!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @CelestinaBeing to this issue.

[drips-wave]

Congratulations, @CelestinaBeing! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @CelestinaBeing: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[grantfox-oss]

🦊 GrantFox — @CelestinaBeing has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #621)
2. Your PR will be reviewed by the FinesseStudioLab maintainers

Good luck! Track your progress on GrantFox.