Re-link restored videos to the new device's photo library

[kmch4n]

Summary

A restored backup returns the log but not the videos. On a device other than the one that produced the file, every restored video is marked unavailable and shows no thumbnail, because the two fields that point at media are device-local:

• videos.assetId is a Photos local identifier and resolves on no other library.
• videos.thumbnailUri is a path under documentDirectory, and that file is not in the backup.

The import (implemented in #72, 2b999bd..f0a137a) already measures this honestly — it checks each asset and writes isFileAvailable = 0 when it cannot be found, and falls back to THUMBNAIL_MISSING_SENTINEL. So the state is correct; it is just not useful.

This is the gap between "your log came back" and "your library came back", and closing it is what would make SnowLog support a device change.

What it would take

Match each restored video against the new device's photo library on the metadata the backup does carry, then repair both fields:

1. After the rows are written, enumerate video assets via mediaService.getVideoAssets().
2. Match on filename + capturedAt + duration. The duplicate-detection scoring in src/services/duplicateDetectionService.ts already solves a very similar problem and is now under test — its thresholds are a reasonable starting point, and the same "is this the same video?" judgement applies.
3. On a confident match, update assetId (updateVideoMeta does not cover it today — videos.assetId has no update path at all) and set isFileAvailable = 1.
4. Regenerate the thumbnail with generateAndSaveThumbnail() and updateVideoThumbnailUri().

Why this needs a decision rather than just doing it

• Matching can be wrong, and being wrong is expensive. A false match attaches a user's memo, tags and diary context to the wrong video. Whether to require an exact triple match, accept a scored match, or ask the user to confirm each ambiguous pair is a product call.
• assetId is unique. If the new library already holds the matched asset under a different video row — which is exactly the collision the import already has to handle — the update violates the unique index. The resolution (skip, merge the two rows, prefer one) is a judgement.
• Cost. Enumerating the whole photo library and regenerating thumbnails for hundreds of videos is minutes of work, needs progress reporting, and probably needs to be resumable.
• Timing. It could run as part of the import, or as a separate "reconnect videos" action the user triggers afterwards. The second is more forgiving — it can be re-run and does not make the import slower — but it is another surface.

Acceptance criteria

• After restoring onto a device whose photo library holds the same videos, the restored entries play and show thumbnails.
• No video is ever attached to the wrong asset without the user confirming it.
• The operation reports progress and can be run again safely.
• Only once this ships may README.md and pr/web/src/content.ts say that migration is supported.

Related

• JSON export is unreachable on every platform and has no import counterpart #72 — export and import. Both are implemented; this is the third piece.

[kmch4n]

#86 would let the user store video inside the app instead of referencing the photo library. That mode removes the recovery path this issue depends on: a copied video's bytes exist only inside the app container, and the JSON backup does not carry them, so there is no assetId to re-link against on the new device.

Whether that regression is acceptable is listed as an open decision in #86 §9.3.