Bedtime shows, dimmed caught-up shows, a show menu, and skip visibility

Four things Peter asked for, plus a crash found while verifying them.

- Bedtime shows. A per-show flag (schema 8->9) that takes a show out of the
  library entirely; the moon icon in the top bar switches to listing only
  those. Not a category system -- the one grouping worth building is the one
  with behaviour attached, which is that entering bedtime mode also arms the
  sleep timer. BedtimePolicy owns the two cases that make that safe: it will
  not overwrite a timer set by hand, and leaving only cancels a timer bedtime
  itself armed. The mode is deliberately not persisted; a restart is morning.

- Shows with nothing waiting are dimmed. Same condition the library sort
  already used -- nothing unplayed and unqueued -- now returned alongside it
  as SubscriptionListing.hasWaiting. That comes from a COUNT rather than the
  sort key on purpose: an episode with no publish date ranks at 0, which is
  right for ordering and would have greyed out a show with one sitting
  unheard. LibraryOrderTest pins that case. The lastError line keeps its
  error colour through the dimming, since a failing feed looks exactly like
  a feed with nothing new.

- Per-show controls moved into an overflow menu and a settings sheet, and
  the tutorial prose is gone. Reaching the episodes used to mean scrolling
  past drip cadence and two paragraphs; Peter wrote the requirements and
  does not need them explained back. Unsubscribe went into the same menu,
  off the top bar where it sat one tap from Refresh.

- Skip detection is visible at last, per show and per episode. SkipSummary
  is pure and its wording is tested, because the distinction that matters is
  confirmed-and-acting versus still-gathering, and "not checked yet" is a
  third state again -- midroll scanning runs nightly, so a fresh download
  legitimately has nothing to say yet.

And the crash. Opening the new readout on a device threw
SQLiteBlobTooBigException, which turned out not to be the readout's fault:
show_fingerprints.pendingClipPcm held a whole decoded head/tail window --
240s at 8kHz is 3.84MB as 16-bit PCM -- and Android reads every Room row
through a CursorWindow that refuses anything over 2MB *on the way out*. The
insert succeeded and the next read threw. Intro/outro detection therefore
died the moment a show's second episode was fingerprinted and could never
have worked as shipped; nothing off-device could have caught it.

Migration 9->10 drops the column and keeps only pendingEpisodeId, re-decoding
on demand -- exactly what midrollPendingEpisodeId already did for the same
reason. StoredClip now owns the limit, MidrollUpdater caps a candidate
segment at 60s before persisting it (a long sponsor block would hit the same
wall) and refuses anything that still would not fit, and StoredClipSizeTest
pins both against the limit so the class cannot come back quietly. Trimming
under-skips a very long break rather than over-skipping into content, which
is the safe direction.

Verified on the emulator: 10 migration tests including the never-before-run
7->8, LibraryOrderTest, and the whole reported flow by hand -- bedtime split,
timer arming and cancelling, the dimmed row, both readouts. Re-ran the exact
sequence that crashed: three downloads, no crash, FingerprintWorker SUCCESS,
and the MP3 decoder visibly running, which is the first time
MediaCodecClipSource has executed on hardware at all.

Still open, and recorded in CLAUDE.md rather than glossed: detection has not
actually confirmed an intro or outro for a real show. Three Up First
downloads left both ends "Nothing found yet". Possibly correct -- the
threshold is strict by design -- or possibly the 8-second reference window
against a roughly 6-second sting. That wants the desktop prototype, not a
guess at a tuned constant.

Coverage 91.76% -> 91.84%.

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

0 files changed, 0 insertions, 0 deletions