Auth Users Vs Apple Subject Uuid Mismatch

1. Add ON UPDATE CASCADE to every FK that points at public.members(id) so the UPDATE in step 2 can safely change the members.id values without breaking child rows. 2. UPDATE the orphaned members rows so members.id = auth.users.id (matched by oauth_provider + oauth_subject via auth.identities.identity_data['sub']). 3. Add a BEFORE INSERT/UPDATE trigger to enforce the invariant going forward (if NEW.id is null OR NEW.id <> auth.uid() → set NEW.id = auth.uid()). 4. Add a UPDATEs-rejection trigger to prevent post-creation changes to members.id (id is immutable after creation).

The 2026-06-24 cascade of 17 commits (per concepts/sign-in-with-apple-fix-recipe-final-verified) was trying to fix this by either: 1. Sending session.user.id (which is auth.users.id) instead of currentMember.id (which is members.id) — works but uses a different UUID than what's stored in public.members 2. Migrating the orphaned members rows so members.id = auth.users.id — works but requires an explicit migration

The new info (the 2 auth.users rows) confirms there's no other Apple-signed-in member to worry about. The migration UPDATE will only touch the 1 member row for Nate (the other member rows — Connor Hansen, Nathan Maxwell — may have different oauth_provider or no auth.users row at all; the UPDATE's WHERE clause filters on oauth_provider = 'apple' AND matching identity_data['sub'], so non-Apple members are untouched).