feat: recipe categories with filter sheet on list

[plusmobileapps]

Summary

Adds recipe menu categories to chef-mate. Two user-facing pieces:

1. EditRecipeScreen now has a Category picker between Description and Star Rating: a flow row of FilterChips (one per category, plus a leading "None" chip) styled to match the existing sort/filter chip pattern. Tapping the selected chip clears it.
2. RecipeListScreen's existing filter bottom sheet gains a new Category section beneath Sort and Filter — multi-select chips, sharing the sheet's existing Clear All + Apply controls. The filter icon's badge counts both legacy filters and category filters via Model.totalActiveFilterCount, so the user gets a single visible indicator that filters are active.

RecipeCategory is an enum with stable string IDs (NOT ordinals — same reasoning as the bottom-nav reorder PR; we don't want renumbering to corrupt persisted data). Defaults: breakfast, lunch, dinner, appetizer, side, dessert, snack, drink, other. Recipes can have at most one primary category. A null category counts as "uncategorized" for filtering and is matched only when the user includes OTHER in the filter set.

Selection persists across config changes / process death via the same Settings layer as the existing sort + filter prefs (key: recipe_list_active_categories, comma-separated stable IDs).

Schema changes

Local (SQLDelight)

• New column category TEXT on Recipe table.
• Migration: client/database/core/.../migrations/7.sqm
• Schema snapshot regenerated at 8.db.

Remote (Supabase) — manual task

A Supabase migration is included as a file in this PR but must be run manually before merging:

File: supabase/migrations/20260508_add_recipe_category.sql

ALTER TABLE recipes
    ADD COLUMN IF NOT EXISTS category TEXT;

Stored as free-form TEXT (no CHECK constraint) to keep parity with how the existing client_id / similar identifier columns are stored on this schema, and so future categories can be added on the client without a coordinated server migration. The client validates known category IDs via the RecipeCategory enum.

Apply command (Supabase CLI):

supabase db push --include supabase/migrations/20260508_add_recipe_category.sql

Or via psql:

psql "$SUPABASE_DB_URL" -f supabase/migrations/20260508_add_recipe_category.sql

Tasks:

• Run migration 20260508_add_recipe_category.sql on staging
• Run migration 20260508_add_recipe_category.sql on production

Sync

RemoteRecipe carries a category: String? field (column name category). The repository's three sync paths (push add, push dirty update, pull from remote) all round-trip the category, so editing a category on one device propagates to others.

Backfill / migration behaviour

Recipes created before this column was added will have null / "Other" category until the user edits them. They appear in:

• The unfiltered list, exactly as before.
• Any filter set that includes the Other category chip.

No data migration is performed — null is treated semantically as "uncategorized" rather than auto-assigned to OTHER, so we can distinguish "user explicitly chose Other" from "user hasn't set a category yet" if we ever want to.

Tests

Unit tests (./gradlew :client:recipe:list:impl:jvmTest :client:recipe:core:impl:jvmTest — passing locally):

• EditRecipeViewModelTest: starting category is null, an existing recipe's category seeds the picker, selecting + saving persists the chosen category, clearing back to null persists null.
• RecipeListViewModelTest: empty filter set returns everything, single-category filter, multi-category union, empty result, OTHER matches null-category recipes, OTHER-not-selected excludes them, category + legacy FAVORITES filter AND together, persistence round-trips through Settings, clearFilters() clears categories.

Screenshot tests (client/ui/screenshot-test/.../RecipeCategoryFilterScreenshotTest.kt):

• Recipe list with an active category filter — light + dark — verifies the badge count and tinted filter icon.
• Sort/filter sheet body with one category pre-selected — light + dark — locks in the new Category section layout.

SortFilterSheetContent was extracted from the ModalBottomSheet wrapper so the screenshot can render the panel directly (Dialog-backed composables don't render reliably under the screenshot plugin).

Conflicts to watch

• PR feat(settings): reorder bottom navigation tabs #163 (bottom nav reorder) touches RecipeListScreen indirectly through navigation/top-bar wiring. This PR adds chips and badge logic inside the existing SortFilterBottomSheet and bumps the badge to use totalActiveFilterCount — should rebase cleanly but the top-bar BadgedBox block is a likely textual conflict if feat(settings): reorder bottom navigation tabs #163 also restyles it.

Test plan

• Create a recipe, pick a category, save — verify it appears with that category after reopening
• Edit an existing pre-category recipe — verify category starts as "None"
• On the list, open the filter sheet, pick two categories, Apply — verify only those recipes show
• Verify the filter icon shows the count badge (2) and is tinted
• Verify "Clear all" empties both filter and category chips
• Pick Other, Apply — verify pre-category recipes match
• Kill the app, relaunch — verify filters persist (matches existing search/sort behaviour)
• Sign in / sync — verify category round-trips to/from Supabase (after running the manual migration)

🤖 Generated with Claude Code

[andrew-steinmetz]

@claude should i be creating a separate table in supabase that is just for the categories and make use of a foreign key in the recipe? using the category name as a string seems fragile if the user were to ever change the category name?