Add native content_filters/skip_title_patterns to "rss" sources - #121

Adds content_filters (CSS-selector / regex cleanup rules, applied to the
extracted article HTML) and skip_title_patterns (regex titles to skip
before fetching) as native, optional fields on the "rss" source type.
Both are ordinary JSON config - no wrapper code required to use them.
- goosepaper/contentfilters.py: apply_content_filters()/should_skip_title(),
 a regex-then-CSS cleanup pass over fetched article HTML.
- goosepaper/storyprovider/rss.py: RSSFeedStoryProvider applies both during
 get_stories(), skipping matched titles before the network fetch and
 stripping matched elements/patterns from the extracted body afterward.
- goosepaper/config.py, goosepaper/util.py: schema validation and provider
 wiring for the two new optional "rss" fields.
Proven in production against 25+ real-world feeds' ad blocks, cookie
banners, and paywall/teaser stubs (heise, t3n, Electrek, netzpolitik, ...).

This branch's original commit added the feature (contentfilters.py,
config.py/util.py validation, RSS wiring) but shipped without dedicated
test coverage or user-facing docs - fixing both ahead of review:
- goosepaper/test_contentfilters.py: unit tests for apply_content_filters
 (css removal, regex stripping, flags, the regex-before-css ordering) and
 should_skip_title.
- goosepaper/storyprovider/test_rss.py: two integration tests proving
 RSSFeedStoryProvider actually applies content_filters to a fetched
 story's body_html and skips entries matching skip_title_patterns before
 they're counted toward `limit`.
- goosepaper/test_config.py: config-schema validation tests - a valid rss
 source with both fields loads correctly; an unknown filter type, a css
 filter without `selector`, a regex filter without `pattern`, and an
 unknown field on a filter object each raise ConfigError with a specific
 message.
- README.md + example-config.json: document both options inline (selector/
 pattern/flags shape, ordering, case-insensitive title matching) and add a
 working example - verified by generating a real PDF from the example
 config end-to-end.

Per review feedback from @j6k4m8 on j6k4m8#121: "content filter" reads as
ambiguous (could mean "filter FOR" as much as "filter OUT"), while
skip_title_patterns is already unambiguous as-is. Adopted his own
suggested name directly - renames the config field, constructor kwarg,
schema validator, and every reference in README/example-config/tests.
skip_title_patterns is intentionally left unchanged (he confirmed it
reads fine as-is). The internal apply_content_filters()/should_skip_title()
helper functions in contentfilters.py also keep their names - this is a
config-surface rename, not an internal-API one.
For future symmetry once accept-mode filters are added (also raised in
review): accept_title_patterns and content_accept_filters would match
each existing field's own word order (verb-first for title, scope-first
for content) rather than forcing both families into an identical shape.
86 tests pass; example-config.json still generates a real PDF end-to-end.

Follow-up to the maintainer's accept/reject nomenclature question on
j6k4m8#121: content_skip_filters/skip_title_patterns are denylists, this adds
their allowlist counterparts.
- content_accept_filters: a list of {"selector": "..."} CSS rules tried
 in order, keeping only the first matching element's contents instead
 of the whole parsed tree. Only CSS is supported (discussed on the PR:
 a regex "accept" would just reduce a story to whatever static phrase
 the pattern matches, not coherent prose) - falls through to the
 original html unchanged if nothing matches, so a miss never zeroes
 out an article.
- accept_title_patterns: a list of regexes; only entries matching at
 least one are kept - e.g. ["amazon", "amzn"] to build a single-company
 ticker out of an otherwise general business feed.
Both apply alongside the existing skip filters (accept narrows first,
then skip cleans whatever junk remains within that narrower selection)
and are entirely additive - existing configs are unaffected.

_validate_content_skip_filters used one combined allowed-keys set for
both filter types, so e.g. {"type": "css", "selector": "...",
"pattern": "never used"} passed validation silently - apply_content_filters()
just ignores "pattern" for a "css" entry, so the typo/confusion had no
error to catch it. Key set is now looked up per "type" instead.
Also precisifies README.md's filter documentation: spells out which
keys are required/optional per type for content_skip_filters, and
explicitly contrasts content_accept_filters' simpler always-CSS shape
(no "type" field at all) rather than leaving readers to infer it by
analogy.

Its sibling was always named should_skip_title, mirroring the config
field skip_title_patterns exactly - but apply_content_filters kept its
pre-rename name when the config field became content_skip_filters
(see 42261ee), on the reasoning that it's config-surface vs. internal
API. That held while there was only one content-filter function; now
that apply_content_accept_filters sits right next to it, the omission
reads as accidental rather than intentional - a reader would
reasonably guess apply_content_filters is "the general one" rather
than immediately seeing "one skips, one accepts".
Also renames the four skip-filter tests in test_contentfilters.py that
still said generic "filter" (test_css_filter_..., test_regex_filter_...)
instead of "skip_filter", for the same symmetry their accept-filter
counterparts already had (test_accept_filter_...).
No behavior change - pure rename, all 105 tests still pass.

The previous rewrite (d258490) made the filter docs more precise but
landed as three dense paragraphs full of "unlike X" cross-references
you had to actively untangle - confusing per feedback. Leads with a
skip/accept x title/content table showing the four fields' relationship
at a glance, then a compact bullet per field instead of comparative
prose. Same content, restructured for scanability.

...ilters/accept_content_filters
Consistent verb-first word order with skip_title_patterns/accept_title_patterns, per
j6k4m8's review comment on PR j6k4m8#121 (the two field families were flips of each other:
skip_title_patterns but content_skip_filters).
Also adds "regex" support to accept_content_filters: unlike the existing "css" type
(narrows kept content to one container), a "regex" entry is a whole-story keep/reject
gate matched against the fetched article's extracted text - e.g. keeping only articles
that actually mention a ticker symbol, the content-level counterpart to
accept_title_patterns. Addresses the same comment's second point about regex-based
accept filtering.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

...ng wiring coverage
The two separate "accepts_*" tests for skip_content_filters/accept_content_filters mostly
duplicated the same generic options passthrough already exercised elsewhere - collapsed into
one combined smoke test covering all four filter fields at once.
More importantly, nothing previously drove a config through
construct_story_providers_from_source_configs() for these four fields, so a typo in util.py's
separate allowed-keys copy of the same field names would pass config.py validation but silently
drop the option before it reached RSSFeedStoryProvider - added
test_construct_story_providers_passes_rss_content_filter_options to close that gap (verified it
fails on a deliberately introduced typo before adding it).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

min_body_text_length skips stories whose extracted body is implausibly
short (almost always a failed extraction). max_body_text_length adds the
inverse: skip stories whose body is implausibly long, e.g. a hardware
review with a huge image gallery/spec dump that would otherwise balloon a
single RSS entry into the bulk of the whole paper. Both optional and off
by default, applied after skip_content_filters/accept_content_filters so
the check sees the same body the reader will.

config.py validated these two fields (added alongside the four content-
filter fields, but without updating this file to match) - a well-formed
"rss" source passed every test_config.py check while the values never
reached RSSFeedStoryProvider at all, silently dropped by util.py's own,
separate allowed-keys set for what actually gets forwarded to the
constructor. Same failure mode the existing
test_construct_story_providers_passes_rss_content_filter_options already
warns about in its own docstring, just not extended to cover these two
newer fields when they were added.
Verified: min_body_text_length/max_body_text_length now reach the
constructed provider end-to-end via load_paper_config() +
construct_story_providers_from_source_configs(), not just Python callers
constructing RSSFeedStoryProvider directly. Full suite: 120 passed.

Tags were replaced with a space but newlines/indentation from pretty-printed
source HTML were never collapsed, so a short teaser-only extraction from a
heavily-indented page could clear min_body_text_length on pure source
formatting rather than real content. A rendered page (or a screen reader)
collapses that whitespace too, so none of it is actually "visible text".