Real SMTP heir notifications — no third-party signup needed

Per explicit direction to use existing VPS/Bitwarden/Gitea infrastructure
instead of waiting on a Resend signup. Bitwarden's MCP unlock/list both
hung (server-side issue, confirmed via direct CLI retry too — not
something to keep retrying), so this used the VPS and Gitea directly.

Found real, working infrastructure already in place: a documented but
never-deployed falah-ibaas email connector (SMTP wrapper) at
/opt/falah-ibaas/connectors/email, backed by a local Postfix relay that
Ghost already uses successfully in production on the same VPS
(mail__options__host=172.17.0.1:25, no auth needed internally).

Built nf-mail-relay: a small HTTP wrapper (Python stdlib, no deps) around
that connector, deployed as a Docker Swarm service on the existing
Traefik network at https://nfmailrelay.falahos.my, bind-mounting the
connector code read-only so it stays in sync with any future updates to
it. Shared-secret bearer auth (X-Relay-Secret) — verified a wrong secret
gets rejected with 401.

notify-heirs Edge Function rewired to call this relay instead of Resend.
Two real bugs found and fixed via actual testing, not code review:
- The function only took memberId, but a person can belong to multiple
  families — .maybeSingle() against multiple trigger rows failed closed
  (correctly, but silently, as "not triggered"). Function and both
  call sites (db.js notifyHeirs, MutawalliDashboard) now require and pass
  familyId too, matching the same composite-key fix already applied to
  the trigger tables themselves.
- No CORS/OPTIONS handling: a browser's preflight OPTIONS request has no
  body, and calling req.json() on it crashed the function before any
  headers were sent — surfaced in the browser as a generic "Failed to
  send a request" with no detail. Added an OPTIONS short-circuit and
  CORS headers on every response path.

Verified with a real send to a live inbox through the full chain
(browser -> Edge Function -> VPS relay -> Postfix -> SMTP), not just a
connectivity check.

Also fixed a stale e2e-trust.cjs assertion using the same
instant-isVisible()-after-fixed-wait pattern already fixed elsewhere in
this session — real app behavior was correct, only the test's timing
assumption was wrong.

e2e-per-member.cjs's heir-notification check now asserts an actual "Sent"
result via the real relay instead of accepting either Sent or a
not-configured failure. Full sweep: e2e-uat 32/32 (stable across 3 runs,
one earlier run's failure was a one-off network blip under heavy parallel
test load), e2e-fastpath 16/16, e2e-trust 12/12 (stable across 3 runs),
e2e-business 10/10, e2e-digital-vehicle 10/10, e2e-property 9/9,
e2e-other 4/4, e2e-info 31/31, e2e-per-member 11/11 — 165/165 total.

e2e-trust.cjs

@@ -51,9 +51,7 @@ async function main() {
   await trustInputs.nth(1).fill('Faridah binti Omar');
   await trustInputs.nth(2).fill('Equal split among 3 children');
   await page.locator('button.btn-primary', { hasText: 'Add trust setup' }).click();
-  await page.waitForTimeout(600);
-
-  const trustRowVisible = await page.locator('.nomination-row', { hasText: 'Land Parcel' }).isVisible();
+  const trustRowVisible = await page.locator('.nomination-row', { hasText: 'Land Parcel' }).waitFor({ state: 'visible', timeout: 10000 }).then(() => true).catch(() => false);
   record('Nomination: trust setup row created for land parcel', trustRowVisible);
 
   const exportBtnVisible = await page.locator('.nomination-row', { hasText: 'Land Parcel' }).locator('.export-btn').isVisible();