feat: cooking assistant can propose adding items to a shopping list

Second tool alongside createRecipe, same safety shape: addToShoppingList's
execute only validates/echoes input, no DB write. The proposal card lets
the user pick an existing list (fetched lazily) or name a new one, then
confirms through the exact two-call flow AddToShoppingListButton already
uses — POST /api/v1/shopping-lists (if new) then POST .../items — no new
persistence code path.

generateMealPlan intentionally not built as a tool: the existing
/api/v1/ai/meal-plan/generate endpoint generates and writes in one step
with a week/preferences input, not a specific plan payload, so it has no
"save this exact draft" entry point to confirm against without a larger
refactor. Documented as a known gap rather than forcing a weaker pattern.

v0.46.0

apps/web/messages/en.json

@@ -465,7 +465,10 @@
     "proposalDiscardButton": "Discard",
     "proposalCreated": "Recipe created — opening editor…",
     "proposalDiscarded": "Discarded",
-    "proposalCreateFailed": "Failed to create recipe"
+    "proposalCreateFailed": "Failed to create recipe",
+    "shoppingProposalTitle": "{count, plural, one {1 item} other {{count} items}} for your shopping list",
+    "shoppingProposalMore": "+{count} more",
+    "shoppingProposalAddButton": "Add to list"
   },
   "conversations": {
     "menuAriaLabel": "Conversations",