Filter the content list by taxonomy term

[eisenbruch]

A collection's content list can be filtered by status, author, byline, date range, free text and any indexed custom field, but not by a taxonomy term, in the admin or over the API. #3043 has the measurements; the short version is that a taxonomy can drive a site's URLs and navigation and still be invisible in the screen editors work in, and the workaround (an indexed select field instead) gives up the shared vocabulary, renaming, term pages and hierarchy that a taxonomy exists for.

#3046 is a working implementation. I opened it before this Discussion, which was the wrong order, so this is here to agree the shape before anyone reviews code.

Proposed shape

A sibling to fieldFilters on GET /content/{collection}:

?termFilters={"topics":["rodeo","polo"],"places":["kentucky"]}

• OR within a taxonomy, AND across taxonomies.
• Resolved as one EXISTS subquery per key against content_taxonomies, in both findMany and the count, so total and cursor pages agree.
• A sibling rather than an extension of fieldFilters, so a field and a taxonomy that share a name cannot collide.
• In the admin, one dropdown per taxonomy already applied to the collection. Nothing is configured per site, and a collection with no taxonomy renders nothing new.

Two failure choices I would like a view on

1. A taxonomy that is not applied to the collection returns VALIDATION_ERROR, rather than an empty list or being ignored.
2. A taxonomy given an empty array matches nothing, rather than meaning "no filter". This mirrors the byline filter's handling of an empty id set.

The broader question: unknown query parameters

Today contentListQuery strips parameters it does not recognize, so ?taxonomy=x&term=y returns the complete, unfiltered list with a 200. That is what made the gap in #3043 slow to find. Making the schema strict would fix it for every filter, but it would also reject any caller that currently sends an extra parameter, so I have not included it in #3046. Is that a change you would want, as its own small PR, or is stripping the intended behavior?

Relation to #1928 and #2799

The overlap bot flags six shared files with each. I have read both: they add the reference field type and touch the create, get and update paths and the ContentItem types. #3046 touches only the list path (handleContentList, findMany, the count, contentListQuery) and the list page's filter bar. Same files, no shared functions, so whichever lands second should be a mechanical rebase. #1206 (draft) also shows up; it shares three admin files and no logic.

Not included

Sorting by a term, and multi-select within one taxonomy in the admin. The parameter already takes an array, so both fit later without changing the API.

If this shape is roughly right, #3046 is ready for review. If you would rather it looked different, I will change it or park it.