feat(family): add families schema, RLS, and invite email

[plusmobileapps]

Stack 1/3 — backend only. No Kotlin changes, so nothing in the app reads any of this yet.

What

A family is a group of accounts that share content across grocery lists, recipe books, and the meal plan. This is the group + membership model and its invite flow. The family_id columns that actually scope the three domains land in later phases.

Families sit alongside the existing per-entity sharing rather than replacing it — nothing here touches grocery_list_members or recipe_book_members, so sharing a single list or book with someone outside your family keeps working.

Three things worth a close look

One family per user is enforced by the database, not the client.

CREATE UNIQUE INDEX idx_fm_one_accepted_family_per_user
  ON family_members (user_id)
  WHERE status = 'accepted' AND user_id IS NOT NULL;

Any number of pending invites are fine; accepting a second fails with 23505. That's what lets current_family_id() return a single unambiguous value for every future policy to compare against.

The helpers are SECURITY DEFINER for a specific reason. The families policies check membership and the family_members policies check family ownership, so without them they'd reference each other's RLS-protected tables and recurse (42P17) — the same failure 20260610_fix_recipe_rls_recursion.sql was written to fix.

current_family() exists because a blanket select would over-fetch. families_invitees_select deliberately widens SELECT to families you've only been invited to, so the invite card can show a name. A plain select() on families would therefore pull an unjoined family into the client's cache — the same shape as the #487 over-fetch. The client (stack 2/3) goes through the RPC instead.

Invite email

notify_invite_email() gains a family branch rather than a second function, so all three invite kinds stay on one code path. The edge function now resolves the parent name and owner through one lookup table covering grocery_lists / recipe_books / families.

No new secrets or Vault setup — it reuses what 20260707_invite_email_notification.sql already established.

Deploying

Prod's schema is hand-managed and its migration history isn't reconciled with the CLI, so this is written to be idempotent and re-runnable. Worth applying it in the SQL editor and running it a second time to confirm before merging.

🤖 Generated with Claude Code