Protect a show's Tier 3 pending episode from retention reclaim

Peter's call (option 1 of the three in docs/detection-findings.md): exempt
an episode retention would otherwise reclaim while it is a show's pending
comparison basis, rather than extending the grace period or accepting the
gap.

RetentionSweeper gains a pendingEpisodeIds seam (suspend () -> Set<String>,
defaulting to empty) and filters its reclaim candidates against it before
the grace-period policy ever sees them -- every existing caller and test
was unaffected by the default. RetentionWorker wires the real thing: the
union of two new, narrow DAO queries --
ShowFingerprintDao.getAllPendingEpisodeIds() (intro/outro) and
MidrollDao.getAllMidrollPendingEpisodeIds() (midroll, reading
SubscriptionEntity.midrollPendingEpisodeId).

Applied to both fingerprinting mechanisms, not just the one that got
diagnosed: MidrollUpdater's discovery has the identical rolling-pending-
episode shape and would race retention the same way for a fast show, just
silently, with no frozen row to reveal it.

Not yet re-verified on a device -- the next live test is two Up First
downloads close enough together to actually compare, confirming
pendingEpisodeId advances to a real second episode instead of restarting.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Sj3CoWEedM56bebByKgNxA

1 files changed, 15 insertions, 9 deletions

diff --git a/CLAUDE.md b/CLAUDE.md
index 76ed20d..8121bfe 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -194,15 +194,21 @@ by default and correct; it is simply waiting for a publisher who marks breaks.
 - **Auto-downloads are not retried.** A rule's download that fails is left FAILED rather than
   requeued: retrying forever against a 404 would burn the battery, and the failed row is visible
   in the episode list. Retry is the manual Download button.
-- **Tier 3 has never confirmed a real intro, outro or midroll.** The pipeline runs on hardware
-  and the worker succeeds, but three consecutive Up First downloads produced no candidate at
-  either end. Two live hypotheses -- an 8-second reference window against a ~6-second sting,
-  and pre-roll ads moving the intro to a different offset in every file. **See
-  `docs/detection-findings.md`**, which is the brief for the desktop session that settles it:
-  what is already known, the experiments in order, and what not to touch. Do not tune
-  `DEFAULT_REFERENCE_SECONDS`, `MIN_SCORE` or `CONFIRM_THRESHOLD` from the app -- the app
-  cannot show you what a change costs in false positives, and the threshold is the whole
-  safety mechanism.
+- **Tier 3 had never confirmed a real intro, outro or midroll, and root cause is now found and
+  fixed.** Not the correlation algorithm -- a real production-algorithm simulation against real
+  Up First audio confirmed cleanly at the app's actual defaults before any of this. The real
+  cause: `RetentionPolicy`'s one-day grace period routinely reclaimed a show's pending episode's
+  file before the next download arrived to compare it against, for a fast, promptly-listened-to
+  show like Up First -- so the detector kept discarding its only candidate and restarting instead
+  of ever comparing two episodes. Confirmed live on the phone (a fresh download's
+  `FingerprintWorker` run replaced the stale pending episode instead of advancing toward a
+  comparison). Fixed by protecting a show's pending episode from reclaim, for both intro/outro
+  and midroll -- `RetentionSweeper` now takes a `pendingEpisodeIds` seam and
+  `RetentionWorker` supplies the union of both mechanisms' pending ids. **Not yet re-verified on
+  a device.** Full history in `docs/detection-findings.md`. Do not tune
+  `DEFAULT_REFERENCE_SECONDS`, `MIN_SCORE` or `CONFIRM_THRESHOLD` from the app -- they were never
+  the problem, the app cannot show you what a change costs in false positives, and the threshold
+  is the whole safety mechanism.
 
 - **Android Auto is verified in a real car**, as of 2026-09-28. It appears, and connects. The
   notification Peter saw on first connect was Android Auto's own new-media-app announcement,