fix(refresh): stop last_processed watermark poisoning that hid new episodes

[ssarunic]

The bug

podcasts.last_processed was overloaded as both the incremental-refresh discovery watermark (newest episode pub_date, compared via episode_date > last_processed) and a wall-clock "we just processed an episode" timestamp written by mark_episode_processed.

Because processing always happens now (after publish), the wall-clock writes pushed the watermark ahead of every real episode. Any newly-published episode whose pub_date fell before the last processing run was then silently skipped by refresh — even though its GUID had never been seen.

Real-world trigger: Moonshots EP #263 (pub Jun 8 18:30) was invisible to "Refresh feeds" because last_processed had been bumped to Jun 8 21:36 by processing an earlier episode. 18:30 > 21:36 is false → skipped.

The fix (separate the two meanings)

• last_processed → discovery watermark only, written by refresh from max(episode pub_date).
• new last_processed_at column → wall-clock processing time, written by a targeted touch_last_processed_at() repo method that can never touch the watermark. API + CLI "last processed" now read it.

One-off repair (idempotent migration)

Runs once per DB on open:

1. adds last_processed_at, backfilled from the old last_processed;
2. resets last_processed = MAX(pub_date) per podcast — un-poisons every watermark;
3. clears stale etag/last_modified so the next refresh does a full parse and re-discovers anything missed (conditional-GET 304s were compounding the bug).

Validated on a copy of prod: 61/61 podcasts' watermarks corrected.

Tests

tests/unit/services/test_refresh_watermark.py:

• mark_episode_processed leaves the watermark but stamps last_processed_at;
• an episode published before a past processing run is still discovered;
• GUID dedup remains authoritative.

Bonus: discrepancy audit

scripts/check_feed_discrepancies.py — read-only DB-vs-RSS audit that distinguishes genuine in-window gaps from the expected never-ingested back-catalogue. Run across all 59 followed feeds it found exactly 1 in-window gap (EP #263) and $21,930 expected back-catalogue episodes correctly ignored.

Notes / follow-ups

• EP #263 was manually imported earlier keyed by its Apple track id (1000771734258), not the feed GUID (5a30b9ce-…, same audio). A post-fix refresh would otherwise duplicate it; reconciling that one row's external_id is a separate manual step.
• The migration already applied to the local prod DB (via the audit script). The running server must be restarted on this code so mark_episode_processed stops re-poisoning.