Stop recipe_update reporting photos and topics as lost

[sysread]

SYNOPSIS

recipe_update answered every edit with an empty photo list and an
empty topic list. Neither was true. It now reads the photo set back
and drops the topics field.

PURPOSE

A recipe edit through the tool came back reporting zero photos and
zero topics, so the model warned the user its edit had probably
dropped three photos and every tag. Nothing had been dropped - the
photos were still on the recipe, and the tags came back on their own 43
minutes later.

The cost is trust in the edit path. A tool that cries data-loss on a
clean write teaches the user to distrust every edit, and teaches the
model to hedge every confirmation.

DESCRIPTION

How it behaved. Two fields, two different failure modes.

• photos - recipe_update never sets the photo set, so it passes
  p_set_image_ids: false and the RPC inherits the previous
  version's links onto the new version. The tool then returned
  photos: [] as a literal, never looking at what it had carried
  forward. A header comment justified this ("the recipe-photo
  manipulation tools aren't ported for v1") - the port landed, the
  comment didn't move.
• topics - the clear_recipe_topics_on_change trigger empties
  the column on any content edit, which is how the recipe-topics
  curation unit knows to re-tag the row. The RPC's return query
  reads the row back after that trigger fires, so the field was
  structurally always [] on this path.

What changes.

• photos - the tool reads the post-write link set back instead of
  asserting a shape. The "newest version's links" query moved out of
  recipe_get into _recipe_helpers.ts::readRecipePhotoMeta, so both
  tools answer photo questions from one read and can't drift.
• topics - stripped from the echoed row. It's re-queue
  bookkeeping, not the recipe's tags, and the only number it can ever
  carry is a misleading zero. recipe_get is the read-back path once
  the unit has caught up.
• schema - the tool description now says the response carries the
  recipe's current photo list and that this tool never edits it.
• tests - tests/recipe_update.test.ts, 6x cases: photos reported +
  position-sorted, topics absent, empty and no-version-row branches,
  p_set_image_ids still false, and the empty-patch rejection.

How that closes it. The response now describes state the tool
actually read, so a clean edit reads as a clean edit.

Notes for reviewers:

• recipe_save's photos: [] is deliberately left alone. A create
  passes p_image_ids: null, so the recipe genuinely has no photos yet
  • that literal is honest, not the same bug.
• Dropping topics from the response is an intentional shape
  change, not an oversight. Adding it back only re-arms the false alarm.
• The topics wipe itself is correct behavior and is untouched here;
  only the reporting of it changed.
• docs/dev/cookbook.md's file list pointed at src/lib/tools/recipe_*.ts,
  which have been schema-only since the function-side port, and at a
  notifyCookbookChanged() contract that no longer exists. Both
  corrected while in the area.
• docs/user/cookbook.md gains the missing consequence: an edited
  recipe really does sit under untagged until the hourly sweep.

---

Generated by Claude Code