[paultristanwagner]

All code in this PR was written by an AI agent (Claude Opus 5.5) working with me; I directed it and tested the results on my own account. Feel free to take, change or drop any part of it.

Part of #73.

Recipes and saved meals can now be deleted. delete_custom_food refuses
them, and the client's own docstring noted that the app deletes foods
through an endpoint the client didn't know. That endpoint is
POST /api/v2/del_food:

{"id": <food_id>, "retire": true, "auth": {…}, "config": {"call_version": 1}}

retire is optional. Verified against the live API with throwaway
recipes:

• with retire: true the recipe leaves search and the get_myfoods
  recipe/meal lists, stays readable by id, and a diary entry that logged
  it is kept. The app sends this when you delete a meal that is already
  logged.
• without the flag the server deletes the recipe outright (get_food
  then answers "not found"), and the diary entry that logged it is
  gone too. The app follows that with
  POST /api/v2/delete_recent_foods {"servingFoodIds": [id]}.
• a hard delete also works on a recipe that was retired before.
• saved meals ("meal": true) behave the same way.

Changes:

• client: delete_recipe(food_id, *, permanent=False). It fetches
  the food under the per-food lock and refuses anything that isn't a
  user-created recipe or meal (source == "Custom" with ingredients).
  It retires by default; permanent=True deletes outright and clears
  the recent-foods entry.
• server: a delete_recipe tool (destructive). Its description
  warns that permanent=True removes the diary entries that logged the
  recipe.
• README: tool table row.
• retire_custom_food's docstring no longer says the delete endpoint
  is unknown.

Plain custom foods keep going through delete_custom_food as before.
Moving them to del_food would be a follow-up if you want it.

https://claude.ai/code/session_01MCJFDo71qoSqTRtcGfkpXJ