[push][P1] Backend — send-push FCM transport + device_tokens.fcm_token

[cestercian]

Part of the FCM push epic #24. The code lands in the cestercian/Artistant (iOS/Supabase) repo — it owns the canonical schema + Edge Functions. It lands INERT (returns 503 without the FCM secret), so iOS is unaffected and this can merge before the operator finishes Firebase setup (phase P3).

Why

Android needs FCM; iOS uses APNs. send-push today signs an APNs JWT and POSTs to api.push.apple.com only. The event/payload contract is already fixed and is reused verbatim — this only adds an FCM transport beside APNs.

Derived from Sources/Artistant/Services/PushService.swift + supabase/functions/send-push/index.ts:

• Events: message, gig_request, booking_confirmed_client, booking_confirmed_artist, booking_reminder_24h, booking_review_request.
• Data keys: artistant_event, artistant_thread_id, artistant_request_id, artistant_booking_id.
• The preview is already server-redacted. The message trigger sends left(NEW.body, 140), and NEW.body is redacted by the BEFORE-INSERT redaction trigger (order-proofed by migration 0060). So the FCM body is safe on a lockscreen and no client-side redaction is needed — the anti-leakage moat holds.

Scope

1. Migration (supabase/migrations/00NN_device_tokens_fcm.sql)

alter table public.device_tokens add column if not exists fcm_token text unique;
alter table public.device_tokens alter column apns_token drop not null;
-- a row is EITHER an APNs or an FCM registration, never neither
alter table public.device_tokens add constraint device_tokens_one_token
  check (apns_token is not null or fcm_token is not null);

iOS is unaffected: its device_tokens reads/writes use explicit columns (never select *) and always write apns_token. Apply dev → prod (dev first, per the 0028 convention).

2. send-push FCM branch (alongside APNs, not replacing)

• Split the recipient's device_tokens rows: APNs for rows with apns_token, FCM for rows with fcm_token.
• FCM HTTP v1: mint an OAuth2 access token from the service-account JSON (FCM_SERVICE_ACCOUNT secret) for scope https://www.googleapis.com/auth/firebase.messaging (cache it ~55 min), then POST https://fcm.googleapis.com/v1/projects/${FCM_PROJECT_ID}/messages:send.
• Transport decision — data-only + high priority. Send a data-only message (NO notification block) so the Android client's onMessageReceived fires in foreground and background — letting it own the channel, suppress a notification for the thread already on screen, and route deep-links consistently. The preview is already redacted, so nothing leaks in data.

{ "message": {
    "token": "<fcm_token>",
    "data": { "artistant_event": "message", "title": "...", "body": "<redacted preview>",
              "artistant_thread_id": "<uuid>" },
    "android": { "priority": "high" } } }

(title/body ride in data since there is no notification block; the client composes the visible notification.)

• Token invalidation: FCM returns 404 UNREGISTERED/NOT_FOUND for a dead token — log it (deletion is the cleanup sweep, same as the APNs 410 handling).
• Fail-loud: if a recipient has an fcm_token but FCM_SERVICE_ACCOUNT is unset, return 503 (so pg_net surfaces the gap) — mirrors the existing APNs-missing 503. The APNs path stays byte-for-byte unchanged.

3. Secrets (operator — tracked in P3)

FCM_SERVICE_ACCOUNT, FCM_PROJECT_ID on both Supabase projects.

Acceptance

• Migration applied dev + prod; device_tokens has nullable apns_token, unique fcm_token, and the one-token CHECK; iOS chat/push unaffected.
• send-push deploys to dev + prod; an FCM-token recipient with the secret set gets a v1 send; without the secret → 503; an APNs-token recipient is unchanged.
• Structural verify only here; real delivery is P4 (needs a device).

Depends on / blocks

• Live delivery needs P3 secrets, but the code merges inert.
• Blocks P4 verification.

[cestercian]

Backend code written — PR up (inert, awaiting your review + merge): cestercian/Artistant#94

• Migration 0069: device_tokens.fcm_token (nullable, unique) + apns_token drops NOT NULL + a one-token CHECK.
• send-push: FCM HTTP v1 branch alongside APNs (OAuth2 JWT-bearer from FCM_SERVICE_ACCOUNT, data-only + priority high). APNs untouched. Fail-loud 503 when the FCM secret is missing.
• Verified: deno check + deno lint clean. NOT applied/deployed — operator step (apply 0069 dev→prod + set FCM_SERVICE_ACCOUNT/FCM_PROJECT_ID, phase P3 [push][P3][operator] Firebase project + google-services.json + FCM secrets #40).

I did NOT merge it (shared prod backend → bot reviews run + owner merges). Written as a solo pass since the review workflow was quota-blocked this week — worth a close look at the FCM OAuth2 signing + the 503 gating.

[cestercian]

P1 backend code is MERGED to cestercian/Artistant main (PR #94, merge commit 950292d) — after addressing 3 Greptile findings: independent per-transport delivery (a missing secret on one transport no longer blocks or falsely-503s the other; partial success returns 200 so the reminder cron doesn't re-send), and an XOR token CHECK so a device row can't double-deliver.

Still OPEN on this issue: the deploy (operator, = phase P3 #40): apply migration 0069 dev→prod, set FCM_SERVICE_ACCOUNT + FCM_PROJECT_ID on both Supabase projects, redeploy send-push. Leaving #37 open until that lands (its acceptance includes 'applied dev+prod').