@mohasinac/appkit 4.35.1 → 4.35.2

package/dist/_internal/shared/features/messaging/config.d.ts

@@ -0,0 +1,108 @@
+/**
+ * Shared vocabulary for "may this message go out, and does the budget allow
+ * it" — the types both the server guard and the settings schema speak.
+ *
+ * Lives in `_internal/shared/` because the channel/audience unions are read on
+ * both sides: the guard enforces them server-side, the admin settings view
+ * renders them.
+ */
+/**
+ * A metered outbound channel.
+ *
+ * `sms` is declared and has no sender. That is deliberate rather than
+ * aspirational: `notificationChannels.sms` has existed in the settings schema
+ * (and been seeded `enabled: true`) for a long time while no code has ever
+ * read it, so anyone adding an SMS provider will reach for this union first
+ * and find the budget already covers them. A channel that is born capped
+ * cannot repeat what email did.
+ */
+export type MessageChannel = "email" | "whatsapp" | "sms";
+/**
+ * Who the message is FOR — which is what the kill switch keys on.
+ *
+ * `user` is a buyer or seller receiving something about their own activity.
+ * `staff` is the operators of the site receiving something about the site.
+ *
+ * The kill switch suppresses `user` only. Turning off customer email must not
+ * also blind the people running the shop: the daily digest is how a support
+ * message or a stuck payment proof gets noticed at all, and silencing it is
+ * how an outage becomes a week-long outage.
+ */
+export type MessageAudience = "user" | "staff";
+/**
+ * What a caller must state before a message can leave the building.
+ *
+ * Every field is required except `transactional`, and that asymmetry is the
+ * point — a sender that cannot say who this is for and why has not thought
+ * about it, and an optional field defaults to whatever is least safe.
+ */
+export interface SendGuardContext {
+    channel: MessageChannel;
+    /**
+     * Stable identifier for WHAT is being sent — a notification type
+     * (`order_shipped`), or a named non-notification flow (`daily_digest`,
+     * `checkout_otp`, `payout_summary`).
+     *
+     * Recorded on every allow and deny, so "what ate the quota today" is a
+     * question with an answer.
+     */
+    feature: string;
+    audience: MessageAudience;
+    /**
+     * The message is part of a flow the user is actively in, and suppressing it
+     * breaks that flow rather than merely quietening it.
+     *
+     * Exempt from the KILL SWITCH ONLY — the daily ceiling still applies, since
+     * the ceiling exists to stop the provider rejecting everything, and a
+     * transactional mail that would be rejected anyway is not worth pretending
+     * about.
+     *
+     * Only two things qualify today and the bar should stay this high:
+     *   · the high-value checkout OTP — the buyer cannot complete an order above
+     *     the threshold without the code;
+     *   · the order confirmation — the buyer's receipt for money already taken.
+     */
+    transactional?: boolean;
+}
+export type SendDecision = {
+    allow: true;
+} | {
+    allow: false;
+    /** Machine-readable, for logs and the suppression record. */
+    reason: "type_ineligible" | "env_disabled" | "admin_disabled" | "daily_ceiling";
+    /** One line, for the log. Never shown to an end user. */
+    detail: string;
+};
+/**
+ * Defaults, mirrored into `DEFAULT_SITE_SETTINGS_DATA.messaging`.
+ *
+ * 🛑 `emailEnabled` and `whatsappEnabled` default to FALSE. An install that
+ * has not made a decision should be quiet, not loud — the opposite default is
+ * how a fresh deploy mails real people from a half-configured site.
+ */
+export declare const MESSAGE_BUDGET_DEFAULTS: {
+    readonly emailEnabled: false;
+    readonly whatsappEnabled: false;
+    readonly dailyCeiling: {
+        /**
+         * Resend's free tier is 100/day. 80 is not timidity — the counter is
+         * reserve-then-send and a burst can race slightly past the check, and
+         * Firebase-side auth mail (password resets, verification) draws on a
+         * different quota but the same inbox reputation. Twenty messages of
+         * headroom is what stops "at the limit" from becoming "over it".
+         */
+        readonly email: 80;
+        /** Meta's pricing is per-conversation, not per-message; this is a sanity bound, not a tier limit. */
+        readonly whatsapp: 200;
+        /** No sender exists yet. Present so one cannot ship uncapped. */
+        readonly sms: 50;
+    };
+};
+/**
+ * Hard kill, checked before any Firestore read so it works even when Firestore
+ * is the thing that is unhappy.
+ *
+ * Any of `1` / `true` / `yes` counts, case-insensitively — an operator setting
+ * this at 3am should not have to remember which spelling the parser wanted.
+ */
+export declare function isEnvKillSwitchOn(): boolean;

package/dist/_internal/shared/features/messaging/config.js

@@ -0,0 +1,44 @@
+/**
+ * Shared vocabulary for "may this message go out, and does the budget allow
+ * it" — the types both the server guard and the settings schema speak.
+ *
+ * Lives in `_internal/shared/` because the channel/audience unions are read on
+ * both sides: the guard enforces them server-side, the admin settings view
+ * renders them.
+ */
+/**
+ * Defaults, mirrored into `DEFAULT_SITE_SETTINGS_DATA.messaging`.
+ *
+ * 🛑 `emailEnabled` and `whatsappEnabled` default to FALSE. An install that
+ * has not made a decision should be quiet, not loud — the opposite default is
+ * how a fresh deploy mails real people from a half-configured site.
+ */
+export const MESSAGE_BUDGET_DEFAULTS = {
+    emailEnabled: false,
+    whatsappEnabled: false,
+    dailyCeiling: {
+        /**
+         * Resend's free tier is 100/day. 80 is not timidity — the counter is
+         * reserve-then-send and a burst can race slightly past the check, and
+         * Firebase-side auth mail (password resets, verification) draws on a
+         * different quota but the same inbox reputation. Twenty messages of
+         * headroom is what stops "at the limit" from becoming "over it".
+         */
+        email: 80,
+        /** Meta's pricing is per-conversation, not per-message; this is a sanity bound, not a tier limit. */
+        whatsapp: 200,
+        /** No sender exists yet. Present so one cannot ship uncapped. */
+        sms: 50,
+    },
+};
+/**
+ * Hard kill, checked before any Firestore read so it works even when Firestore
+ * is the thing that is unhappy.
+ *
+ * Any of `1` / `true` / `yes` counts, case-insensitively — an operator setting
+ * this at 3am should not have to remember which spelling the parser wanted.
+ */
+export function isEnvKillSwitchOn() {
+    const raw = process.env.EMAIL_DISABLED?.trim().toLowerCase() ?? "";
+    return raw === "1" || raw === "true" || raw === "yes";
+}

package/dist/_internal/shared/features/notifications/action-url.js

@@ -155,4 +155,13 @@ export const TYPE_AUDIENCE = {
     account_action: "buyer",
     system: "buyer",
     promotion: "buyer",
+    /*
+     * Both are "buyer" because that is where the RECIPIENT reads them — the
+     * ticket's owner at `/user/support`, the reporter at the scam registry.
+     * Staff do not receive either of these as notifications any more: the
+     * per-employee fan-out was replaced by a single `adminNotifications` row
+     * plus a daily digest section, so there is no staff audience to express.
+     */
+    support_ticket_update: "buyer",
+    scam_report_update: "buyer",
 };

package/dist/_internal/shared/features/notifications/email-eligibility.d.ts

@@ -0,0 +1,66 @@
+/**
+ * May this notification type be EMAILED at all?
+ *
+ * ## Why this is code and not the admin allow-list
+ *
+ * `siteSettings.notificationChannels.email.types?: NotificationType[]` already
+ * exists and is checked inside `sendNotification`. Setting it in the seed would
+ * have been one line — and the wrong one, three times over:
+ *
+ *   · it is a plain array, so a NEW notification type is silently
+ *     email-enabled. A `Record<Union, boolean>` makes it a compile error
+ *     instead (Root Cause #61 — a Record is compile-safe, an array is not);
+ *   · its empty case means "all types allowed", so an admin clearing the field
+ *     reopens every one of them;
+ *   · it is data, so a reseed quietly restores the old behaviour.
+ *
+ * So the two layers compose in one direction only: **this map decides what is
+ * eligible, the admin list may narrow it further, and neither can widen past
+ * here.**
+ *
+ * ## What this is actually protecting
+ *
+ * Resend's free tier is 100 emails/day, and three call sites could exhaust it
+ * on their own:
+ *
+ *   · `auctionSettlement` sends `bid_lost` to every losing bidder, up to 50 in
+ *     PARALLEL per auction, and settles all expired auctions concurrently —
+ *     two auctions is the whole day;
+ *   · `onScamReportCreate` fanned out one send per employee, up to 100;
+ *   · `bid_outbid` is one email per bid per bidder on a live auction.
+ *
+ * The gate runs FIRST in `sendNotification`'s channel conjunctions — before the
+ * settings read, before the budget counter — so those 50 sends now exit with
+ * zero Firestore operations. That ordering is load-bearing: it is what lets the
+ * daily counter stay a single unsharded document.
+ *
+ * ## Nothing is lost by dropping a type from here
+ *
+ * `sendNotification` writes the in-app notification BEFORE any channel
+ * decision, so an ineligible type still fills the bell. Only the emailed copy
+ * goes away.
+ */
+import type { NotificationType } from "../../../../features/admin/schemas/firestore";
+/**
+ * `true` = may email (subject to the admin allow-list, the kill switch, the
+ * user's own preference and the daily ceiling). `false` = in-app bell only.
+ *
+ * Typed on the union so a new notification type cannot compile without an
+ * answer to "is this worth an email?". Do not reach for a default — the whole
+ * value of this map is that the question gets asked once, deliberately, per
+ * type.
+ */
+export declare const EMAIL_ELIGIBLE_TYPES: Record<NotificationType, boolean>;
+/**
+ * Prefer this over indexing the map directly — the lookup is `boolean`, and a
+ * bare `EMAIL_ELIGIBLE_TYPES[type]` inside a long `&&` chain reads as a flag
+ * rather than as a decision.
+ */
+export declare function isEmailEligible(type: NotificationType): boolean;
+/**
+ * For the admin UI, which renders an ineligible type as a DISABLED row rather
+ * than hiding it. Hiding would leave an admin wondering why `bid_outbid` is
+ * absent from a list that claims to cover every type; a disabled row with a
+ * reason answers the question in place.
+ */
+export declare const EMAIL_INELIGIBLE_TYPE_LIST: readonly NotificationType[];

package/dist/_internal/shared/features/notifications/email-eligibility.js

@@ -0,0 +1,129 @@
+/**
+ * May this notification type be EMAILED at all?
+ *
+ * ## Why this is code and not the admin allow-list
+ *
+ * `siteSettings.notificationChannels.email.types?: NotificationType[]` already
+ * exists and is checked inside `sendNotification`. Setting it in the seed would
+ * have been one line — and the wrong one, three times over:
+ *
+ *   · it is a plain array, so a NEW notification type is silently
+ *     email-enabled. A `Record<Union, boolean>` makes it a compile error
+ *     instead (Root Cause #61 — a Record is compile-safe, an array is not);
+ *   · its empty case means "all types allowed", so an admin clearing the field
+ *     reopens every one of them;
+ *   · it is data, so a reseed quietly restores the old behaviour.
+ *
+ * So the two layers compose in one direction only: **this map decides what is
+ * eligible, the admin list may narrow it further, and neither can widen past
+ * here.**
+ *
+ * ## What this is actually protecting
+ *
+ * Resend's free tier is 100 emails/day, and three call sites could exhaust it
+ * on their own:
+ *
+ *   · `auctionSettlement` sends `bid_lost` to every losing bidder, up to 50 in
+ *     PARALLEL per auction, and settles all expired auctions concurrently —
+ *     two auctions is the whole day;
+ *   · `onScamReportCreate` fanned out one send per employee, up to 100;
+ *   · `bid_outbid` is one email per bid per bidder on a live auction.
+ *
+ * The gate runs FIRST in `sendNotification`'s channel conjunctions — before the
+ * settings read, before the budget counter — so those 50 sends now exit with
+ * zero Firestore operations. That ordering is load-bearing: it is what lets the
+ * daily counter stay a single unsharded document.
+ *
+ * ## Nothing is lost by dropping a type from here
+ *
+ * `sendNotification` writes the in-app notification BEFORE any channel
+ * decision, so an ineligible type still fills the bell. Only the emailed copy
+ * goes away.
+ */
+/**
+ * `true` = may email (subject to the admin allow-list, the kill switch, the
+ * user's own preference and the daily ceiling). `false` = in-app bell only.
+ *
+ * Typed on the union so a new notification type cannot compile without an
+ * answer to "is this worth an email?". Do not reach for a default — the whole
+ * value of this map is that the question gets asked once, deliberately, per
+ * type.
+ */
+export const EMAIL_ELIGIBLE_TYPES = {
+    // ── Money. The buyer is owed something, owes something, or just paid. ──────
+    order_placed: true,
+    order_confirmed: true,
+    order_shipped: true,
+    order_delivered: true,
+    order_cancelled: true,
+    refund_initiated: true,
+    payment_review: true,
+    emi_installment_due_soon: true,
+    emi_installment_overdue: true,
+    // ── Negotiation. Each one is a move the other party must respond to, and ──
+    // ── every one of them expires if they do not.                            ──
+    offer_received: true,
+    offer_responded: true,
+    offer_expired: true,
+    offer_counter_accepted: true,
+    // Won, and on a clock: the winner forfeits the lot if they miss the payment
+    // deadline. This is the one auction type that survives, and it survives
+    // BECAUSE of the deadline — not because winning is nice to hear about.
+    bid_won: true,
+    // Someone must claim this, and the claim window closes.
+    prize_won: true,
+    // Access to the account itself — a ban or an unban. After the 2026-09 split
+    // this means ONLY that; support tickets and scam reports moved to their own
+    // types precisely so this one could keep emailing. A banned user has to be
+    // told outside the app, because the app is what they just lost.
+    account_action: true,
+    // Signup and genuine one-off announcements. Low volume by nature.
+    welcome: true,
+    system: true,
+    // ── Bell only. ────────────────────────────────────────────────────────────
+    // The three auction fan-outs. `bid_lost` is up to 50 parallel sends per
+    // settled auction; `bid_outbid` is one per bid per bidder; `bid_placed`
+    // pings the seller on every single bid. All three are visible on the auction
+    // page and in the bell, and none of them is a deadline.
+    bid_lost: false,
+    bid_outbid: false,
+    bid_placed: false,
+    auction_ended: false,
+    // Marketing. The likeliest way to get the sending domain flagged, and the
+    // first thing a recipient marks as spam — which damages deliverability for
+    // the transactional mail above.
+    promotion: false,
+    product_available: false,
+    // Nothing for the user to do; the record is on the site when they next look.
+    review_approved: false,
+    review_replied: false,
+    // Housekeeping nags. `catalogue_images_stale` loops one send per stale item,
+    // so it is a quiet fan-out of its own.
+    catalogue_images_stale: false,
+    prize_reveal_expired: false,
+    // The conversation lives in the UI. Routine ticket back-and-forth costs
+    // nothing; a staff replier who genuinely needs one to land in an inbox ticks
+    // "also email the user", which sends `eligibilityOverride: "staff_requested"`
+    // for that one reply. The user side has no such tick — a user replying to
+    // their own ticket never triggers mail.
+    support_ticket_update: false,
+    // The reporter reads the outcome on the site; the admin side rides the daily
+    // digest. This was the second 100-way fan-out — `onScamReportCreate` sent one
+    // notification per employee, up to 100, for every report filed.
+    scam_report_update: false,
+};
+/**
+ * Prefer this over indexing the map directly — the lookup is `boolean`, and a
+ * bare `EMAIL_ELIGIBLE_TYPES[type]` inside a long `&&` chain reads as a flag
+ * rather than as a decision.
+ */
+export function isEmailEligible(type) {
+    return EMAIL_ELIGIBLE_TYPES[type] === true;
+}
+/**
+ * For the admin UI, which renders an ineligible type as a DISABLED row rather
+ * than hiding it. Hiding would leave an admin wondering why `bid_outbid` is
+ * absent from a list that claims to cover every type; a disabled row with a
+ * reason answers the question in place.
+ */
+export const EMAIL_INELIGIBLE_TYPE_LIST = Object.freeze(Object.keys(EMAIL_ELIGIBLE_TYPES).filter((t) => EMAIL_ELIGIBLE_TYPES[t] === false));

package/dist/constants/api-endpoints.d.ts

@@ -23,6 +23,16 @@ export declare const AUTH_ENDPOINTS: {
     readonly SESSION_ACTIVITY: "/api/auth/session/activity";
     readonly SESSION_VALIDATE: "/api/auth/session/validate";
     readonly EVENT_INIT: "/api/auth/event/init";
+    /**
+     * Cooldown gate the client asks BEFORE calling Firebase's own
+     * `sendPasswordResetEmail` / `sendEmailVerification`.
+     *
+     * Those go browser → Firebase with no server hop, so this is the only
+     * throttle they have — nothing else on our side ever sees them. Advisory by
+     * design: a failure here resolves to "allowed", because a user locked out of
+     * their account must not also be locked out by our infrastructure.
+     */
+    readonly MAIL_GATE: "/api/auth/mail-gate";
 };
 export declare const ACCOUNT_ENDPOINTS: {
     /** @param userId — Firestore user document id */
@@ -480,6 +490,16 @@ export declare const API_ENDPOINTS: {
         readonly SESSION_ACTIVITY: "/api/auth/session/activity";
         readonly SESSION_VALIDATE: "/api/auth/session/validate";
         readonly EVENT_INIT: "/api/auth/event/init";
+        /**
+         * Cooldown gate the client asks BEFORE calling Firebase's own
+         * `sendPasswordResetEmail` / `sendEmailVerification`.
+         *
+         * Those go browser → Firebase with no server hop, so this is the only
+         * throttle they have — nothing else on our side ever sees them. Advisory by
+         * design: a failure here resolves to "allowed", because a user locked out of
+         * their account must not also be locked out by our infrastructure.
+         */
+        readonly MAIL_GATE: "/api/auth/mail-gate";
     };
     readonly ACCOUNT: {
         /** @param userId — Firestore user document id */
@@ -939,6 +959,16 @@ export declare const API_ROUTES: {
         readonly SESSION_ACTIVITY: "/api/auth/session/activity";
         readonly SESSION_VALIDATE: "/api/auth/session/validate";
         readonly EVENT_INIT: "/api/auth/event/init";
+        /**
+         * Cooldown gate the client asks BEFORE calling Firebase's own
+         * `sendPasswordResetEmail` / `sendEmailVerification`.
+         *
+         * Those go browser → Firebase with no server hop, so this is the only
+         * throttle they have — nothing else on our side ever sees them. Advisory by
+         * design: a failure here resolves to "allowed", because a user locked out of
+         * their account must not also be locked out by our infrastructure.
+         */
+        readonly MAIL_GATE: "/api/auth/mail-gate";
     };
     readonly ACCOUNT: {
         /** @param userId — Firestore user document id */

package/dist/constants/api-endpoints.js

@@ -35,6 +35,16 @@ export const AUTH_ENDPOINTS = {
     SESSION_ACTIVITY: "/api/auth/session/activity",
     SESSION_VALIDATE: "/api/auth/session/validate",
     EVENT_INIT: "/api/auth/event/init",
+    /**
+     * Cooldown gate the client asks BEFORE calling Firebase's own
+     * `sendPasswordResetEmail` / `sendEmailVerification`.
+     *
+     * Those go browser → Firebase with no server hop, so this is the only
+     * throttle they have — nothing else on our side ever sees them. Advisory by
+     * design: a failure here resolves to "allowed", because a user locked out of
+     * their account must not also be locked out by our infrastructure.
+     */
+    MAIL_GATE: "/api/auth/mail-gate",
     /*
      * RESEND_VERIFICATION was here and is gone. The route was deleted in the
      * Firebase-native auth migration (Root Cause #54: the Admin SDK cannot send

package/dist/constants/notification-types.d.ts

@@ -29,7 +29,7 @@ import type { NotificationType } from "../features/admin/schemas/firestore";
 export { NOTIFICATION_TYPE_VALUES };
 export type { NotificationType };
 /** Alias kept for the two existing importers. */
-export declare const NOTIFICATION_TYPES: readonly ["order_placed", "order_confirmed", "order_shipped", "order_delivered", "order_cancelled", "bid_placed", "bid_outbid", "bid_won", "bid_lost", "auction_ended", "review_approved", "review_replied", "product_available", "promotion", "system", "welcome", "account_action", "offer_received", "offer_responded", "offer_expired", "offer_counter_accepted", "refund_initiated", "prize_won", "prize_reveal_expired", "emi_installment_due_soon", "emi_installment_overdue", "payment_review", "catalogue_images_stale"];
+export declare const NOTIFICATION_TYPES: readonly ["order_placed", "order_confirmed", "order_shipped", "order_delivered", "order_cancelled", "bid_placed", "bid_outbid", "bid_won", "bid_lost", "auction_ended", "review_approved", "review_replied", "product_available", "promotion", "system", "welcome", "account_action", "support_ticket_update", "scam_report_update", "offer_received", "offer_responded", "offer_expired", "offer_counter_accepted", "refund_initiated", "prize_won", "prize_reveal_expired", "emi_installment_due_soon", "emi_installment_overdue", "payment_review", "catalogue_images_stale"];
 /**
  * `order_shipped` → `Order shipped`.
  *

package/dist/features/admin/actions/notification-actions.d.ts

@@ -28,6 +28,26 @@ export interface SendNotificationInput extends NotificationCreateInput {
      * the seller, `offer_responded` back to the buyer.
      */
     audience?: NotificationAudience;
+    /**
+     * Bypass `EMAIL_ELIGIBLE_TYPES` for THIS send, because a human explicitly
+     * asked for it.
+     *
+     * The only caller is the support-ticket reply route, where a staff member
+     * ticked "also email the user" on a reply. `support_ticket_update` is
+     * ineligible by default precisely so routine back-and-forth costs nothing —
+     * this is the escape hatch for the reply that genuinely has to reach an
+     * inbox.
+     *
+     * 🛑 It bypasses ELIGIBILITY ONLY. The kill switch, the daily ceiling, the
+     * channel config and the user's own opt-out all still apply — a staff tick
+     * is a request, not an override of the site's posture or of the recipient's
+     * stated preference.
+     *
+     * Deliberately a named literal rather than `boolean`: a `force: true` reads
+     * as "send harder" at the call site and invites reuse, while
+     * `"staff_requested"` states who is accountable for the send.
+     */
+    eligibilityOverride?: "staff_requested";
 }
 export interface SendNotificationResult {
     notification: NotificationDocument;

package/dist/features/admin/actions/notification-actions.js

@@ -8,6 +8,7 @@ import { enqueueJob } from "../../jobs/actions/enqueue-job";
 import { serverLogger } from "../../../monitoring";
 import { decryptPii } from "../../../security/index";
 import { resolveNotificationActionUrl, TYPE_AUDIENCE, } from "../../../_internal/shared/features/notifications/action-url";
+import { isEmailEligible } from "../../../_internal/shared/features/notifications/email-eligibility";
 import { renderNotificationEmail } from "../../email/notification-templates";
 /**
  * A notification's `actionUrl` is a site-relative path — correct for the
@@ -111,7 +112,7 @@ export async function getUnreadNotificationCount(userId) {
  *   5. The required credentials are set in siteSettings.credentials
  */
 export async function sendNotification(input) {
-    const { userEmail, userPhone, emailHtml, audience, ...notifInput } = input;
+    const { userEmail, userPhone, emailHtml, audience, eligibilityOverride, ...notifInput } = input;
     /*
      * Fill `actionUrl` when the caller did not.
      *
@@ -131,6 +132,35 @@ export async function sendNotification(input) {
         ...notifInput,
         ...(resolvedActionUrl ? { actionUrl: resolvedActionUrl } : {}),
     });
+    /*
+     * 🛑 The eligibility gate, and it is FIRST for a reason.
+     *
+     * `EMAIL_ELIGIBLE_TYPES` (see that file for the full argument) decides
+     * whether a type may leave the building at all. Checking it here — before
+     * the siteSettings read and before the user-prefs read — is what makes the
+     * expensive fan-outs free:
+     *
+     *   `auctionSettlement` sends `bid_lost` to up to 50 losing bidders in
+     *   parallel per auction. Each of those calls would otherwise pay TWO
+     *   Firestore reads (settings + user doc) to arrive at "skipped". That is
+     *   100 reads per auction to send nothing, and every expired auction settles
+     *   concurrently.
+     *
+     * Returning here costs zero reads, and it is also what lets the daily send
+     * counter stay a single unsharded document: the only remaining concurrent
+     * fan-out never reaches the counter.
+     *
+     * The bell is already filled by the write above, so nothing is lost — this
+     * suppresses the emailed/messaged COPY, not the notification.
+     *
+     * One map gates both channels deliberately. If a type is ever genuinely
+     * WhatsApp-worthy but not email-worthy, split the map then rather than
+     * loosening this early return.
+     */
+    if (!isEmailEligible(notifInput.type) &&
+        eligibilityOverride !== "staff_requested") {
+        return { notification, email: "skipped", whatsapp: "skipped" };
+    }
     // Load channel config + credentials (one Firestore read).
     let settings;
     try {
@@ -204,6 +234,18 @@ export async function sendNotification(input) {
         // "Your catalogue photos are going stale" — housekeeping about the user's
         // own account, which is what `system` covers.
         catalogue_images_stale: "system",
+        /*
+         * Both land under `system` rather than getting new preference keys.
+         *
+         * Same reasoning as the EMI note above: an eighth and ninth key would have
+         * no stored value on any existing user, so it reads as on or off purely by
+         * accident of the default — a silent migration nobody asked for. And
+         * neither is something a user would plausibly want to silence
+         * independently: a ticket update is a reply to a conversation THEY started,
+         * and a scam-report outcome is the answer to a report THEY filed.
+         */
+        support_ticket_update: "system",
+        scam_report_update: "system",
     };
     const typeKey = typeToPrefsKey[type];
     // If the user has explicitly disabled this notification type, skip all external channels.