Use an item's thumbnail as its picture

Resolves in order of deliberateness: itunes:image, media:thumbnail, a
media:content that says it is an image, then an image enclosure -- which
is where a blog's article picture actually lives, so those entries had
artwork available all along and showed none. Audio enclosures are never
taken for pictures.

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

PROGRESS.md

@@ -56,6 +56,24 @@ and until now nothing set them.
 
 ---
 
+## 2026-09-10 — An item's picture
+
+An item's artwork now resolves in order of how deliberate the source is: `itunes:image`, then Media
+RSS `media:thumbnail`, then a `media:content` that declares itself an image, and finally an image
+**enclosure**. That last one matters here -- Substack puts each article's header picture in an
+`<enclosure>`, which is why those blog entries had no artwork despite carrying one all along. Audio
+enclosures are never mistaken for pictures.
+
+Backfilling needed the validators cleared first: `record_entry` fills a missing image on update, but
+a 304 skips parsing entirely, so the feeds would have kept their blank squares. (The self-heal added
+earlier only fires when a feed has *zero* entries, which was not the case here.)
+
+Result across the library: 325 of 3470 entries now carry their own picture, 13 feeds where every
+entry has one, 69 feeds that publish no per-item image at all -- those fall back to the feed's
+artwork, which is the intended behaviour rather than a gap.
+
+---
+
 ## 2026-09-10 — Database cleanup, and the 304 trap it walked into
 
 Cleaned up on request: removed the `CT Log Archive Torrents` folder (123 preallocated files from the