fix(taxonomy): pin matched-driven join order for subtree filters

The pivot rewrite (399fe8e) JOINed an unindexed `matched_n` CTE to the
collection but left the join order to the planner. On D1 the planner drove
the outer loop from the collection's recency index and full-scanned
`matched_n` per candidate row — O(rows_walked × matched_set). A production
trace read ~3.4M rows / 4s for a sparse-against-recency selection where the
old EXISTS read ~44k / 68ms.

Lead the FROM with `matched_0 CROSS JOIN <collection>` on SQLite so the plan
is pinned to the matched set as driver (collection probed by id); SQLite never
reorders across a CROSS JOIN. Postgres keeps a plain JOIN — its cost-based
optimizer with hash joins never incurs the per-row scan, and `CROSS JOIN ... ON`
isn't valid Postgres syntax.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: MA2153

packages/core/src/loader.ts

@@ -956,30 +956,45 @@ export function emdashLoader(): LiveLoader<EntryData, EntryFilter, CollectionFil
 								)}`
 							: sql``;
 
-					// Subtree filters use a *pivot-driven* plan rather than a correlated
-					// EXISTS. Each filter contributes a recursive `sub_n` CTE (the
-					// translation-group subtree walk) and a `matched_n` CTE of DISTINCT
-					// entry_ids tagged anywhere under that subtree, then JOINs `matched_n`
-					// to the collection. This resolves matching entries from
-					// content_taxonomies first — driven by idx_content_taxonomies_term,
-					// reading only the taggings under the subtree — instead of walking the
-					// collection in sort order and probing per candidate. The EXISTS plan
-					// was entry-driven and degraded toward O(table) reads when the selected
-					// subtree is sparse against the recency sort, which is exactly the
-					// faceted-browse case this operator exists for.
+					// Subtree filters use a *pivot-driven* plan. Each filter contributes a
+					// recursive `sub_n` CTE (the translation-group subtree walk) and a
+					// `matched_n` CTE of DISTINCT entry_ids tagged anywhere under that
+					// subtree. Matching entries are resolved from content_taxonomies first
+					// (driven by idx_content_taxonomies_term, reading only the taggings
+					// under the subtree), then the collection is probed by primary key.
+					//
+					// The join order is PINNED, not left to the planner. On SQLite/D1 the
+					// only join strategy is a nested loop and a CTE cannot carry an index,
+					// so if the planner is free to drive the outer loop from the
+					// collection's recency index (to early-exit an `ORDER BY <recency>
+					// LIMIT n`) it full-scans the unindexed `matched_n` once per candidate
+					// row — O(rows_walked × matched_set). For a selection that is sparse
+					// against the recency sort (the faceted-browse case this operator
+					// exists for) rows_walked approaches the whole table: a production D1
+					// trace showed this read ~3.4M rows / 4s where the old correlated
+					// EXISTS read ~44k / 68ms. Leading the FROM with
+					// `matched_0 CROSS JOIN <collection>` forces SQLite to drive from the
+					// small matched set and probe the collection by id — it never reorders
+					// across a CROSS JOIN. The tradeoff: a near-root selection covering most
+					// rows now sorts the (large) matched set instead of early-exiting the
+					// recency index, but that is a bounded O(n log n) and far rarer than the
+					// sparse case the free plan made pathological.
+					//
+					// Postgres has a cost-based optimizer with hash joins, so it never
+					// incurs the per-row scan and keeps a plain JOIN (and `CROSS JOIN ... ON`
+					// is not valid Postgres syntax anyway).
 					//
 					// Multiple subtree taxonomies AND together as successive JOINs (set
 					// intersection). `matched_n` is DISTINCT on entry_id (a text id) so each
 					// JOIN is 1:1 — no row fan-out, no SELECT DISTINCT, so the Postgres
 					// json-column DISTINCT hazard (which is why sibling filters use EXISTS)
-					// never arises here. Always pivot-driven: a near-root selection covering
-					// most rows is mildly suboptimal versus the old early-exit, but bounded,
-					// and rare next to the sparse case the EXISTS plan made pathological.
+					// never arises here.
 					const subtreeCteParts: ReturnType<typeof sql>[] = [];
-					const subtreeJoinParts: ReturnType<typeof sql>[] = [];
+					const matchedAliases: ReturnType<typeof sql.ref>[] = [];
 					subtreeFilters.forEach((f, i) => {
 						const subAlias = sql.ref(`sub_${i}`);
 						const matchedAlias = sql.ref(`matched_${i}`);
+						matchedAliases.push(matchedAlias);
 						subtreeCteParts.push(
 							sql`${subAlias}(grp) AS (${subtreeGroupsCteBody(f.name, f.roots, subAlias)})`,
 						);
@@ -990,9 +1005,6 @@ export function emdashLoader(): LiveLoader<EntryData, EntryFilter, CollectionFil
 									AND taxonomy_id IN (SELECT grp FROM ${subAlias})
 							)`,
 						);
-						subtreeJoinParts.push(
-							sql`JOIN ${matchedAlias} ON ${matchedAlias}.entry_id = ${sql.ref(tableName)}.id`,
-						);
 					});
 					// `WITH RECURSIVE` covers the whole list; the non-recursive `matched_n`
 					// CTEs are permitted alongside the recursive `sub_n` ones on both
@@ -1002,8 +1014,27 @@ export function emdashLoader(): LiveLoader<EntryData, EntryFilter, CollectionFil
 						subtreeCteParts.length > 0
 							? sql`WITH RECURSIVE ${sql.join(subtreeCteParts, sql`, `)} `
 							: sql``;
-					const subtreeJoins =
-						subtreeJoinParts.length > 0 ? sql`${sql.join(subtreeJoinParts, sql` `)}` : sql``;
+
+					// FROM clause. Without subtree filters it is the bare collection table.
+					// With them, SQLite leads with the first matched set and CROSS JOINs the
+					// collection to pin the matched-driven order (see above); any further
+					// subtree filters join by id. Postgres leaves ordering to its optimizer.
+					const tableRef = sql.ref(tableName);
+					let fromClause: ReturnType<typeof sql>;
+					if (matchedAliases.length === 0) {
+						fromClause = tableRef;
+					} else if (isPostgres(db)) {
+						const joins = matchedAliases.map(
+							(m) => sql`JOIN ${m} ON ${m}.entry_id = ${tableRef}.id`,
+						);
+						fromClause = sql`${tableRef} ${sql.join(joins, sql` `)}`;
+					} else {
+						const [first, ...rest] = matchedAliases;
+						const restJoins = rest.map((m) => sql`JOIN ${m} ON ${m}.entry_id = ${tableRef}.id`);
+						fromClause = sql`${first} CROSS JOIN ${tableRef} ON ${first}.entry_id = ${tableRef}.id${
+							rest.length > 0 ? sql` ${sql.join(restJoins, sql` `)}` : sql``
+						}`;
+					}
 
 					// `_emdash_content_bylines.byline_id` stores the byline's
 					// translation_group (migration 040), so a credit spans every
@@ -1038,8 +1069,7 @@ export function emdashLoader(): LiveLoader<EntryData, EntryFilter, CollectionFil
 							: sql`LIMIT -1 OFFSET ${offset}`;
 					}
 					result = await sql<Record<string, unknown>>`
-						${withClause}SELECT ${sql.ref(tableName)}.*, ${termsSelect}, ${bylinesSelect} FROM ${sql.ref(tableName)}
-						${subtreeJoins}
+						${withClause}SELECT ${tableRef}.*, ${termsSelect}, ${bylinesSelect} FROM ${fromClause}
 						WHERE deleted_at IS NULL
 						AND ${statusCondition}
 						${localeFilter}