fix(backfill): convert exiftool-legacy rows whose only dates are zero

backfill_utc_dates refused any fs_time re-resolution of a tag-dated row,
assuming exiftool had failed on the file. Files whose date tags are all
0000:00:00 (e.g. uv-prod-long.mp4) were read fine and simply have no
date, so they sat unconverted and re-ran through exiftool every tick.

resolve_dates_batch_report now also returns the paths exiftool read
without error (-Error surfaces ExifTool:Error in the JSON). The drain
lets fs_time stand for an exiftool-legacy row only when exiftool read
the file; read errors / missing entries and kamadak exif-legacy rows
keep refusing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CLAUDE.md

@@ -458,7 +458,10 @@ the file. Missing-file rows are paged past without spending the cap, and
 a per-library resume cursor (carried across ticks by the watcher, wraps
 at end of table) keeps unconvertible rows from stalling the rows behind
 them; EXIF/exiftool-legacy rows wait when exiftool is absent (they'd
-otherwise fall to fs_time). When a converted row's display-zone day differs from
+otherwise fall to fs_time), and a re-resolution to fs_time never replaces
+a tag date — except an `exiftool`-legacy row that exiftool read cleanly
+and found no usable date in (all-zero tags), where fs_time is the honest
+answer (`resolve_dates_batch_report`'s `exiftool_read`). When a converted row's display-zone day differs from
 the day its legacy value rendered on, the `day`-span `precomputed_reels`
 rows covering either month-day (this library + `all`) are deleted and
 unlinked; the nightly pre-gen regenerates. Daily conversation summaries