fix(dates): year-gate the filename wall-clock patterns (#160)

match_filename_date only gated the unix-timestamp branch to years
1995..=now+1; the five wall patterns returned any NaiveDateTime. Counters
and IDs shaped like YYYYMMDD_HHMMSS (an app's VID_<counter>_<HHMMSS>,
Facebook's <8 digits>_<id>_o.jpg) became dates of record in years from
267 to 9985: 67 rows on prod, all via screenshot_compact.

Both branches now share plausible_filename_year; a wall miss falls
through to the next pattern and then the rest of the waterfall. The
filename audit no longer proposes these dates.

A data migration clears the five date columns on filename-sourced rows
dated outside [1995, 2028) UTC, so backfill_missing_date_taken
re-resolves them from EXIF / exiftool / fs time on the next ticks.

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

migrations/2026-10-16-000000_reresolve_implausible_filename_dates/up.sql

@@ -0,0 +1,23 @@
+-- #160: the filename wall-clock patterns had no year gate, so counters and
+-- IDs shaped like YYYYMMDD_HHMMSS (`VID_22290524_080551.mp4`, Facebook's
+-- `10530519_101527…_o.jpg`) became dates of record in years like 1053 and
+-- 2229. The matcher now rejects years outside 1995..=now+1; this clears
+-- the rows it already dated so they're re-resolved by the fixed waterfall.
+--
+-- Both the legacy pair and the new-contract triple are cleared:
+-- `date_taken IS NULL` puts the row back in `backfill_missing_date_taken`,
+-- which rewrites all five columns (EXIF / exiftool / fs_time now that the
+-- filename no longer matches). Only filename-sourced rows dated outside
+-- [1995-01-01, 2028-01-01) UTC are touched; a real date re-resolves to
+-- itself anyway.
+UPDATE image_exif
+SET date_taken = NULL,
+    date_taken_source = NULL,
+    date_utc = NULL,
+    camera_offset_minutes = NULL,
+    date_taken_tz_source = NULL
+WHERE date_taken_source = 'filename'
+  AND (
+    date_taken < 788918400 OR date_taken >= 1830297600
+    OR date_utc < 788918400 OR date_utc >= 1830297600
+  );