feat(family): Manage Family (part 1: schema, data layer, screens)

[plusmobileapps]

Summary

First part of Manage Family, a new More-tab entry for creating families and managing who is in them. This is a draft: the backend, the data layer and the screen contracts are here, but nothing is wired into the app yet.

Permission rules (enforced server-side, mirrored in FamilyPermissions)

Action	Owner	Admin	Member
Invite as member	✅	✅	❌
Invite as admin, promote or demote	✅	❌	❌
Remove a member or cancel their invite	✅	✅	❌
Remove an admin	✅	❌	❌
Remove the owner	❌	❌	❌
Rename	✅	✅	❌
Delete the family	✅	❌	❌
Leave	❌ (deletes instead)	✅	✅

In this PR

• supabase/migrations/20260916_add_families.sql:
  • New families and family_members tables. Access rules only allow reads.
  • Every write goes through a SECURITY DEFINER RPC that checks the rules above.
  • Invites work by email: the invitee accepts or declines, and a declined invite stays visible as rejected.
  • Seeds the manage_family flag row with rollout_percent = 0.
• FeatureFlagRegistry.ManageFamily (manage_family, default off).
• client/family/data/{public,impl,testing}:
  • FamilyRepository (online only) calling the RPCs, FamilyPermissions, and a FakeFamilyRepository that enforces the same rules.
  • Unit tests for the permissions and the repository mapping (16 tests, all passing).
• client/family/manage/public:
  • Interfaces for ManageFamilyRootBloc, FamilyListBloc and FamilyDetailBloc.
  • FamilyListScreen and FamilyDetailScreen: member and invite lists, a per-member menu for promote, demote and remove, the invite form (role picker for the owner only), rename, and leave or delete with confirmation.
  • Strings and test tags.

Remaining before this is ready

• client/family/manage/impl: bloc and view-model implementations with unit tests.
• More tab: a Manage Family row, shown behind the flag in every auth state.
• Root navigation: open Manage Family when signed in. Otherwise open sign-in first, then land on Manage Family once it succeeds.
• Notifications: show family invites with Accept and Decline.
• Snapshot tests (previews, screenshot-test wrappers, reference PNGs).
• impl-robots and a flow test through runRootBlocTest.
• Apply the migration (supabase db push).
• Follow-up: invite emails for family invites through send-invite-email.

Test plan

• ./gradlew :client:family:data:public:jvmTest :client:family:data:impl:jvmTest
• ./gradlew :client:family:manage:public:compileKotlinJvm :client:composeApp:compileKotlinJvm
• ./gradlew :client:featureflag:impl:jvmTest
• Apply the migration to a dev project and try the RPCs as owner, admin and member.

🤖 Generated with Claude Code