#1147 /feed: filter and search by author, title/text, and topic

Problem statement

The /feed (https://swamp-club.com/feed) is a growing chronological stream of judge-gated posts, and it only gets longer. Right now the only way to navigate it is scanning top-to-bottom and paginating with NEXT — there is no way to narrow the stream to what you actually want. Three concrete needs, all currently unmet:

• By author — "show me everything mgreten has shipped" requires paging through the whole feed and eyeballing the author byline on every entry.
• By title / text — there is no search box, so finding a post you half-remember ("the one about receipts") means manual scanning.
• By topic — there is no way to slice the feed to a subject area (e.g. agents, infra, security), so discovery is all-or-nothing.

As the feed scales, scan-and-paginate degrades: relevant posts get buried and the feed stops being a discovery surface. This is orthogonal to the other open feed work — read-state tracking (#1137), comment removal + redesign (#959), and link-rot handling (#1138) — none of which address narrowing the stream by a query.

Proposed solution

Add a filter/search affordance to the feed header that narrows the ranked stream by query. These are facets of one capability (narrow-by-query) sharing one UI surface and one backend query path, so treating them together:

1. Author filter. Filter to a single author (byline click-through, or an author picker). Author is already first-class data on every entry, so this is shippable without new modeling.
2. Title / free-text search. A search box matching post title (and optionally source domain / excerpt). Also existing data.
3. Topic / tag filter. Slice by subject area. Dependency: posts do not appear to carry a topic/tag field today, so this likely needs a lightweight tagging step first (author-supplied tags, judge-assigned, or inferred at ingest). Called out here rather than split into a separate ticket so the filter UI is designed once with topic in mind, even if topic ships in a later pass.

Filters should compose (author + text together), reflect in the URL so a filtered view is linkable/shareable, and degrade gracefully to the current full feed when empty.

Alternatives

• Author-only, defer text and topic — solves the loudest case but leaves search and topic slicing unaddressed; the filter UI would likely be rebuilt when they land.
• Three separate tickets (author / title / topic) — maximum granularity, but fragments a single coherent design discussion (one filter bar, one query path) across three issues.
• Client-side filtering of the current page only — cheap, but only filters the ~30 loaded entries, not the whole feed, so it misses exactly the buried-post problem that motivates this.
• Do nothing, rely on redesign (#959) — that redesign is about presentation/density and comment removal, not query-based narrowing; the needs are distinct.