Look at a feed's artwork only when it may have changed, and trace a scan's database work (#95, #96)

A feed read in full checked its own artwork and, without one, asked its website for an icon,
every time; a feed without validators is read in full every scan, so looking-for-group spent
2 s of every scan loading lfg.co's home page. Now the check runs when the feed names different
artwork from what is stored, or the scan was asked for, which keeps #80's point: a refresh
still picks up an icon the site changes or fixes.

Feed spans ran seconds past their fetch with nothing to say where (#96). The artwork lookup,
the loop that stores each item, and the per-feed database calls (feed_summary, record_feed,
subscribers, adopt, skipped_by_filter, rehide, pending) now have spans of their own.

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

CHANGELOG.md

@@ -23,6 +23,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
+- A scan's trace shows the time a feed spends on its artwork and in the database after the fetch.
 - The JSON log carries each line's `trace_id` and `span_id`, logs each scan event once instead of
   twice, names a failure's kind in `error.type` (and its HTTP status in
   `http.response.status_code`), and calls a request's time `duration_ms` instead of `ms`.
@@ -47,6 +48,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Fixed
 
+- A scan no longer asks a feed's website for its icon every time; it asks again when the artwork changes or you refresh the feed.
 - The feed list loads several times faster: it was asking the database six questions per feed.
 - Artwork a feed offers only over plain http shows on the https site too.
 - A failing feed is easy to spot in any theme: a mark on its artwork, what is wrong in place of