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/fr.json

@@ -465,7 +465,10 @@
     "proposalDiscardButton": "Ignorer",
     "proposalCreated": "Recette créée — ouverture de l'éditeur…",
     "proposalDiscarded": "Ignorée",
-    "proposalCreateFailed": "Échec de la création de la recette"
+    "proposalCreateFailed": "Échec de la création de la recette",
+    "shoppingProposalTitle": "{count, plural, one {1 article} other {{count} articles}} pour votre liste de courses",
+    "shoppingProposalMore": "+{count} de plus",
+    "shoppingProposalAddButton": "Ajouter à la liste"
   },
   "conversations": {
     "menuAriaLabel": "Conversations",