Auto-plan taxonomy-filtered listings from cached per-term counts

[MA2153]

Problem

On SQLite/D1, a taxonomy-filtered collection listing —
getEmDashCollection("posts", { where: { category }, orderBy, limit }) — applies the
taxonomy filter as a correlated EXISTS on a SELECT * FROM ec_<collection> ... ORDER BY ... LIMIT ?. A stats-blind D1 planner drives from the collection's order index and probes
the taxonomy per row. For a selective term the LIMIT never fills, so the query walks
the whole collection — tens of thousands of D1 rows read for a page returning a handful
(#1834). On D1, rows-read is the billed/throttled unit.

The planner can't fix this on its own: choosing the fast plan requires knowing the term's
selectivity, and D1 is stats-blind (sqlite_stat1 is never maintained). That one fact has
to come from us.

Proposal

Let the loader plan taxonomy-filtered listings automatically from cached per-term entry
counts.

• The count is the missing fact. It inherits the query's own
  collection + status + locale, so a term's count equals the rows that plan would
  actually fetch. No fixed "published" semantics are imposed — the count follows the query
  (a draft query counts drafts, a French query counts French, one collection counts only
  its slice).
• Single term: seek a selective term (drive from content_taxonomies, seek the
  composite pivot index, join the collection by primary key, sort the small candidate set)
  or keep the EXISTS scan for a non-selective one (the LIMIT fills fast). The choice is
  a √(pageRows · total) cost-model crossover.
• Multi-term AND: drive the seek from the smallest-count term and probe the rest as
  index-nested-loop EXISTS — the O(|small|·log|big|) plan, which drives from the most
  selective term rather than the least.
• Advisory invariant: counts change how rows are fetched, never which rows come
  back (the seek and scan paths are tested to return identical results). A stale or wrong
  count only degrades plan quality, which is what makes eventual-consistency caching safe
  here.
• No new staleness machinery. The count map lives in the existing object-cache under
  [content:<collection>, taxonomies]. The existing epoch graph already fires on exactly
  the writes that move a count — content create/delete/status-change/attach bump
  content:<collection>; term rename/delete bumps taxonomies. No new SQL table, no
  write-path hooks, no reconciler.
• Reusable primitive. Keyed by translation_group, carrying name/slug/count plus a
  collection total, so a future public "term counts" API (and the admin term-cloud /
  archive-nav counts) can reuse the same load.

A composite index on content_taxonomies(taxonomy_id, collection, entry_id) (migration
051) backs the seek — it seeks on both leading columns so a term shared across collections
reads only the queried collection's slice. Postgres is unchanged (keeps EXISTS; it has
statistics).

Evidence (real D1)

Against a real dataset (~24k published rows in the collection, ~76k content_taxonomies
rows), rows-read:

Case	seek	scan
Selective term (2 matches)	10	50,609
Broad term (~50% of the collection)	51,099	68
Multi-term AND, drive smallest vs largest	14	51,103

The cost-model threshold picks correctly in both real single-term cases with margin.

Scope

• This change: the count primitive, the loader auto-decision, and migration 051's
  composite index.
• Deliberately out of scope (fast follow): rewiring the admin term-cloud /
  archive-nav counts (today status-agnostic, cross-collection, invalidated only by
  taxonomy writes) onto this published, correctly-invalidated per-collection map. That's a
  visible behavior change (public counts would drop drafts) and needs cross-collection
  aggregation.

Seeking maintainer sign-off on: planning taxonomy listings automatically from cached
counts, the object-cache-based count primitive with its coarse per-collection
invalidation, and the out-of-scope split.

[MA2153]

Closing in favor of a new approach