Notifications fire and forget because email is not a dependency

The portal sends five types of email notification — session notes added, milestone status changed, comment posted, deliverable uploaded, action item assigned. Every one is a plain text email sent through Resend with a single API call. No HTML template, no inline CSS, no image hosting. Just lines of text joined with newline characters. Every notification follows the same shape. A greeting using the client's first name extracted with split and index zero. A one-sentence update explaining what changed. A link back to the portal. A sign-off. The subject line includes the project name so the client can see which project the update relates to without opening the email. Every notification is called with a catch that swallows errors — fire and forget. If Resend is down, the notification silently fails. The admin action still succeeds. The database still updates. The portal still reflects the change. The email is a courtesy, not a dependency. The getResend function checks for the API key at call time, not import time. If the key is missing — in CI, in local development, in a test environment — the function returns null and every notification function returns early. No conditional imports, no environment checks scattered through the codebase. One null check in one factory function. The notification guard also checks whether the client has a clerkId before sending. If I create a client record through the admin panel before they sign up, they do not get bombarded with emails for every update. Notifications only fire for clients who have actually joined the portal.