feat(family): Manage Family (part 2: blocs, navigation, notifications)

[plusmobileapps]

Summary

Completes Manage Family, picking up the checklist left in #541. That PR landed the schema, the data layer and the screen contracts; nothing was wired into the app. This wires it all up.

Remaining items from #541

• 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) — left to you, see below.
• Follow-up: invite emails for family invites through send-invite-email.

Notable decisions

The list reloads on resume, not in init. FamilyListBlocImpl refreshes via lifecycle.doOnResume, so a family renamed, left or deleted on the detail screen is reflected on the way back without the navigation bloc having to poke the list. Only the first load shows a spinner; a later refresh that fails keeps the list already on screen rather than swapping it for an error.

Per-row actions are derived, not hand-set. FamilyDetailViewModel builds every MemberItem through FamilyPermissions, so the UI can only offer what the server would accept. The same helper generates the per-role snapshot previews, so the owner/admin/member references can't drift from the rules.

Manage Family is offered in every auth state. Unlike the Notifications row (signed-in, non-anonymous only), this one shows whenever the flag is on. It's the feature's only entry point, so hiding it from a signed-out user would leave them nothing to tap. RootBlocImpl remembers the destination, opens sign-in, and lands them on Manage Family once auth succeeds — at the credentials screen or at the OTP screen. Backing out of that sign-in forgets the destination, so an unrelated sign-in later doesn't strand them somewhere they didn't ask for. An anonymous guest counts as signed out here: family membership is keyed on an account email, which they don't have.

Notification sources are now caught independently. Adding families as a third source meant a single runCatching around the merge would let one unreachable source blank the others. Each is caught on its own now.

The family invite email trigger fires on INSERT or UPDATE. Grocery and recipe-book invites are plain inserts; invite_family_member instead flips a previously rejected row back to pending. The trigger guards on the row having just become pending, so accepting an invite or changing a role doesn't re-send the mail. The edge function's per-kind parent table and wording moved into one lookup, so a fourth kind is a single entry.

Still needed before this can ship

• supabase db push for 20260916_add_families.sql (from feat(family): Manage Family (part 1: schema, data layer, screens) #541) and 20260921_family_invite_email.sql. I left these unapplied — prod's migration history is unreconciled with the CLI, so that's a call for you to make.
• supabase functions deploy send-invite-email.
• Flip manage_family above rollout_percent = 0 when you're ready.

Test plan

• ./gradlew test — green, including 26 new view-model tests, 8 root-navigation tests and 6 flow tests.
• ./gradlew :client:ui:screenshot-test:validateDebugScreenshotTest — green; 12 new Manage Family references plus refreshed Notifications and More-tab ones, all visually inspected.
• ./gradlew :client:composeApp:compileDebugKotlinAndroid :client:composeApp:compileKotlinJvm :client:composeApp:compileKotlinIosSimulatorArm64
• Apply both migrations to a dev project and exercise invite → email → accept/decline end to end as owner, admin and member.

🤖 Generated with Claude Code