feat: social profiles — claim a handle and publish recipes to it (phase 1)

[plusmobileapps]

Adds the social layer to Chef Mate: you claim a @handle, get a public profile, and can publish recipes to it. Others open your profile from https://chefmate.plusmobileapps.com/@handle, browse what you've published, and save copies.

Phase 1 only. Follows, feed, likes, comments and global discovery are deliberately out of scope — they all build on the profiles table this adds.

The decision worth reviewing first

Publishing uses a new recipes.published_at, deliberately separate from is_public.

is_public (20260713, widened to anon in 20260715) means "readable by anyone holding the unguessable share link" — a capability URL, deliberately unlisted. If profiles had listed every is_public row, then on the day this ships, every recipe every user has ever shared by link would retroactively appear on their new public profile. That's a privacy regression, so listing gets its own explicit opt-in column.

Publishing implies is_public — a listed recipe has to be readable — enforced by a DB CHECK and mirrored in the repository. Sharing never implies publishing. Unpublishing delists but leaves is_public alone, so a link already handed out keeps working; revoking that is the separate "Stop sharing link" action users already have.

There are tests asserting the split in both directions.

Why profiles is a new table

Every user-facing identity field lived in auth.users.raw_user_meta_data, which anon/authenticated cannot read — by design. A public profile needs a publicly-readable row, so identity is mirrored into public.profiles. The mirror deliberately carries no email.

The blanket public SELECT on profiles is safe because having a row is opt-in: you have no profile until you deliberately claim a handle, so enumeration can only ever reveal people who chose to be public. That's the distinction the TO authenticated policy in 20260713 got wrong.

Handles are permanent

Immutable via trigger, and retired into reserved_handles on delete rather than freed. Otherwise deleting an account would let a stranger claim @you and inherit every link, screenshot and mention that ever pointed at you — the same impersonation vector the immutability rule exists to close, reached through a different door.

The cost: a user who deletes their account can never reclaim their own handle. That's a deliberate trade and it's reversible — drop trg_profiles_retire_handle if you'd rather recycle them.

Two things to know before merging

1. The migration has not been applied to prod. It was verified against a local Postgres with a harness stubbing auth.users, auth.uid(), the anon/authenticated roles and the out-of-band recipes table — 36 checks covering handle validation, the publish/share split, RLS for owner / stranger / anon, the Public recipes show up on everyone's account even when they just sign up #487 sync guard, and cascade. Given the known prod schema drift, re-verify there before applying.
2. iOS Universal Links won't route /@handle into the app until the apple-app-site-association in the chefmate-site repo allows that path. Until then those links open the website. Android is done (pathPrefix="/@"). That change lives outside this repo and must land alongside.

What's here

• Backend — profiles (immutable lowercase handle, bio, avatar), reserved_handles, recipes.published_at + partial index, and SECURITY DEFINER RPCs for lookup and listing. The listing gets its own explicit source of truth rather than leaning on how permissive RLS policies compose — the failure mode behind Public recipes show up on everyone's account even when they just sign up #487. get_accessible_recipes() needs no change, so published recipes never pollute anyone else's sync.
• Data — new client/profile/data/{public,impl,testing}. Remote-only, no SQLDelight mirror: a profile is only meaningful fetched fresh, so failures render an Offline state with retry.
• Handle claiming — folded into the existing ManageProfileBloc rather than a new screen; it already edits display name and avatar. Debounced availability check, with the UNIQUE index as the real authority.
• Profile screen — one ProfileBloc for both your own and someone else's, since they differ only in which header actions show. Tapping a recipe reuses the existing PublicRecipeBloc, which already handles "save a copy".
• Publishing — Publish / Remove from profile on recipe detail, routing to the editor if no handle is claimed yet.

A real bug caught while recording snapshots

The profile screen's LazyColumn nested inside PlusHeaderContainer's own verticalScroll produced blank 68-byte PNGs — a scrollable measured with infinite height throws. That would have crashed the real screen too, not just the snapshot. Fixed with scrollEnabled = false, the same way RecipeListScreen does it.

Testing

• 985 tests pass, including new coverage for the publish/share split, handle claiming and the race between check and save, /@handle parsing (including that a lookalike host and a route-shaped handle both behave), and a runRootBlocTest flow: no profile → create → claim → back to profile.
• 16 screenshot references recorded and validated (own / visitor / empty / no-profile / not-found / offline / dark, plus the three handle states). Existing ManageProfile references re-recorded since the screen gained two fields.
• Commits are split by concern for review: schema, then data layers, then one per BLoC with its tests, then snapshots, then robots.

🤖 Generated with Claude Code