v0.3.0rc3

Let a consumer trust its cache instead of re-fetching it

trust_cached_entries (default False) serves a cache entry as it is on disk: no staleness re-fetch, and no full-text retry.

Staleness re-fetching suits a cache the tool owns and can rebuild. For a cache that is committed to a repository and reviewed it inverts — the re-fetch becomes the risk rather than the repair. Three failures reported downstream were the same re-fetch seen from different angles:

• an unstamped full_text_html entry withheld, pointing at a repair route that cannot be reached (dismech#12672)
• a fetch returning PMC's bot-check page on an HTTP 200, its <title> then compared against the curated title (dismech#12867)
• a re-fetch shortening 64 bodies and breaking snippets that had verified, in a pull request about something else (dismech#12879)

Setting the flag removes the fetch, so there is no window in which any of them can happen. The default is unchanged, so caches still migrate for consumers that want that.

The trade is explicit: an imperfect cached entry stays imperfect. That is a content problem to fix deliberately — cache reference --force still rebuilds one on purpose — rather than something re-litigated on every validation run.

Also in this release

Review follow-ups from #94: a test for the refused-overwrite path that consumers actually take (the previous tests only covered _stale_fallback), a stale-HTML warning that no longer advises a retry that cannot succeed for a PMC-only article, find_pmc_article_body made public since two modules share it, and a note that PMC_ARTICLE_BODY_CLASSES is ordered by priority.

Full changelog: v0.3.0rc2...v0.3.0rc3