Decide how derived data is refreshed when a file is replaced in place

Summary

Decide what happens to derived data when a file is replaced in place. Follow-up to #2039 (fixes #730).

Current behaviour after #2039

When the scanner detects that a file at an existing path now has different content, it moves the File and Photo rows to the new hash and deletes the old thumbnails so they regenerate. Faces, captions, tags, CLIP embeddings, OCR text and similar data that were computed from the old picture stay attached to the photo, so search and face results describe an image that no longer exists.

Options

1. Clear all derived data on replacement and bump added_on so the background jobs (faces, captions, embeddings, OCR) pick the photo up again on their next run. Simplest and always correct, but a user who replaced a photo with a slightly edited version loses manual face labels.
2. Clear only machine-generated data and keep user edits (manually labelled faces, ratings, album membership, user-added tags). Needs a per-field notion of "user authored".
3. Leave as is and document it, with the re-hash job (separate issue) as the way to force a refresh.

A product decision is needed before implementing. Option 2 is probably the right long-term behaviour; option 1 is a quick improvement over the current state.