fix(api): don't count $ne/$nin-excluded languages toward the language cap (#1764)

[johan-bell]

What & why

The /query universal validator enforces a per-request language cap for non-CMS queries by collecting the distinct language ids a selector references. walkSelector collected every string leaf whose nearest owning field is language.

The bug: exclusion operators start with $, so walkSelector preserved owningField = "language" when descending into them. That meant:

{ language: { $ne: "fr" } }            // "fr" counted toward the cap
{ language: { $nin: ["fr", "de", …] } } // every excluded id counted toward the cap

Exclusion operators narrow the result — they reference languages the query wants to exclude, not include — so they should never count toward the cap. This was a latent over-count that could reject a perfectly legitimate narrowing query.

Change

• New EXCLUSION_OPERATORS set ($ne, $nin). When walkSelector descends into one, it clears the owning field so the excluded ids aren't collected.
• Included ids (equality / $eq / $in) still count exactly as before.
• Tests: $nin over-cap exclusion accepted, $ne exclusion on top of an at-cap $in accepted, and a mixed case proving over-cap inclusions are still rejected while a sibling exclusion is ignored.

Verification

npx jest src/validation/query/validateQuery.spec.ts → 46 passed (11 in the language-cap block, incl. 3 new).

Closes #1764

[ivanslabbert]

Review summary — 🟡 Approve with nits

Small, clean fix (+56 −5). No squash-merge diff artifact here — origin/main is an ancestor of the branch and the two-dot delta equals the three-dot diff, so no rebase needed.

• Fix is correct for the ticketed cases. validateQuery.ts:240-245 sets nextOwningField = undefined when descending into $ne/$nin, so their string leaves never satisfy owningField === "language" at the collection point (:193). Positive selectors ($eq/$in/bare equality) are untouched — the cap still applies exactly as before.
• Mixed / sibling cases hold. Owning-field clearing is scoped to the $ne/$nin subtree only, so a sibling $in under the same language/$and still counts (verified by the new test). Nested $or/$and preserve context correctly.
• Null-guard contract preserved. $nin stays in ARRAY_OPERATORS, so the $in:[null] → CouchDB function_clause guard (:224-228) still fires — that check runs on the key before owning-field computation, independent of this change.
• Good test coverage (validateQuery.spec.ts:261-297): over-cap $nin accepted, $ne on top of an at-cap $in accepted, over-cap $in with sibling $nin still rejected. API-only /query validation — no DTO/FTS/sync-query contract impact.
• Requested change (latent edge case): a $not-wrapped inclusion — {language: {$not: {$in: [...many]}}} — is semantically an exclusion but is still counted toward the cap, because $not is a LOGICAL_OPERATOR (preserves owning field) and the inner $in also preserves it. It's outside the literal ask of Latent: language validator counts exclusion operators toward cap #1764 and $not on a scalar language field is unusual, but since we're closing the "exclusion operators shouldn't count" gap, please either handle $not-wrapped $in/$eq consistently or add a one-line comment documenting that $not is intentionally excluded from this fix.

_{🤖 AI-assisted review summary (Claude Code). Read-only analysis of the PR diff — not a substitute for human review.}

[MrDirkelz]

LGTM.