Add offline article-image caching behind a setting

[davidfwatson]

Adds an optional, off-by-default setting that caches article images during refresh and
serves them from a local cache at render time, so articles read with images while offline
(planes, trains, tunnels, metered data). Addresses #1873; a step toward #3460.

Design note: what happens when you turn it on

Prefetch only catches images from future refreshes, so the moment you enable this —
typically right before you lose connectivity — your existing unread articles still have
no cached images. To bridge that, enabling the setting offers to cache images for your
current unread articles right away (a "Cache Images Now? / Not Now" prompt showing the
unread count). There's deliberately no standalone "cache everything" button: if you want
to backfill again later, toggle the setting off and back on.

How it works

Two halves sharing an on-disk cache:

• Prefetch: ArticleImagePrefetcher watches .AccountDidDownloadArticles, extracts
  <img> URLs off the main thread (a sync can deliver a large batch at once), and fetches
  them via ArticleImageDownloader — throttled, not one unbounded burst. The pure
  URL-extraction is a nonisolated, unit-tested ArticleImageURLExtractor.
• Serve: with the setting on, main.js rewrites http(s) <img src> to
  nnwimage://cache/?u=…; ArticleImageSchemeHandler (a WKURLSchemeHandler) resolves
  those memory → disk → network. Uncached images load online-only; cached ones load
  offline. On rewrite it also drops the img's srcset and, inside a <picture>, its
  sibling <source> candidates, so WebKit can't select an original https URL that
  bypasses the cache. The enable flag reaches main.js as a hidden DOM marker rather than
  an inline <script>, so it applies even when the reader has article JavaScript off (that
  setting gates content JS; main.js runs as an injected user script).

ArticleImageDownloader mirrors the existing ImageDownloader/FaviconDownloader pattern
(same Downloader, ImageMetadataDatabase backoff, BinaryDiskCache) but keeps full-size
bytes in a separate ArticleImages folder. Same-URL requests coalesce; the in-memory
NSCache is bounded (~50 MB, cleared on background/low-memory); only plausible image
responses persist (an image/* type or recognized magic bytes, under a 20 MB cap). App-side
fetches reuse the web view's content blocker via ArticleImageContentBlocker, so tracker/ad
URLs stay blocked — including on cross-host redirects. The ArticleImages folder is swept by
the existing 3-day CacheCleaner flush, and purged outright when the setting is off.

The setting

cacheImagesForOffline, off by default — iOS: Settings → Articles; Mac: Settings → General.
While a backfill runs, the settings line shows live progress ("Caching Images… N of M");
when idle it shows the current cache size ("166 images · 63.5 MB used"). iOS account-stats
gains an Offline Images section with the same figures.

Key limitations

• Custom-scheme routing bypasses WebKit's own image cache and doesn't send its cookies/referer,
  so a few hotlink-protected images may fail when the setting is on.
• Enclosure/media caching (video, audio, PDF) is out of scope ([Feature] Enclosure caching #5284).
• No pre-buffer byte cap: the 20 MB limit keeps oversized bodies out of the persistent cache,
  but the shared RSWeb.Downloader still buffers whole bodies first. A streaming cap belongs in
  Downloader (it affects every image path) and is left as shared-infra follow-up.

Testing

• macOS and iOS both build clean.
• ArticleImageURLExtractorTests covers absolute / relative / protocol-relative resolution,
  scheme lowercasing, data-canonical-src preference, entity decoding, non-http rejection,
  dedup, ordering.
• Manual: enable → accept the prompt → Airplane Mode → confirm article images still load.

(Full internals live in the three commit messages: core caching, on-enable backfill, and the
Mac prefs-pane sizing fix.)

[davidfwatson]

Rebased onto the latest main (now at 808403b00).

Since this PR was opened, main refactored RSWeb.Downloader.download(_:) to return a DownloadResponse struct instead of a (Data?, URLResponse?) tuple. The rebase merged cleanly textually but broke the build at that API boundary, so I updated ArticleImageDownloader.performDownload to the new signature — matching the sibling ImageDownloader / SingleFaviconDownloader call sites. No behavioral change. Both the iOS and macOS targets archive clean again.