Filter grammar: search / OR-AND / leading-wildcard / in-cap / nesting-cap are TS-only — decide cross-port or document as TS-only-by-design

[dmealing]

Context

A unit-test → conformance survey (FR-033 follow-up) found that five generated-API filter-grammar features are implemented only in the TypeScript runtime (runtime-ts filter-parser). The other four ports (Java, Kotlin, Python, C#) do not implement them. They are therefore not conformance-promotable today — a shared fixture would fail four lanes.

This issue tracks the product decision: implement these cross-port, or formally document them as TS-only-by-design.

TS-only features (audited, with per-port evidence)

Feature	TS	Java	Kotlin	Python	C#	Fix size
?search=<term> (OR a LIKE across @filterable string fields)	✅	❌	❌	❌	❌	Medium (runtime, ~50 LOC/port)
filter[or][N] / filter[and][N] boolean combinators	✅	❌	❌	❌	❌	High (recursive parser, all 4)
Leading-wildcard LIKE gating (@leadingWildcard opt-in → filter.leading_wildcard_disallowed 400)	✅	❌	❌	❌	❌	Medium-High (allowlist + runtime + possibly a metamodel attr)
in-list size cap (>100 → 400)	✅	❌	❌	❌	❌	Low (~5 LOC/port)
Filter nesting-depth cap (>5 → 400)	✅	❌	❌	❌	❌	Low (depends on OR/AND)

Evidence: TS impl in server/typescript/packages/runtime-ts/src/drizzle-fastify/filter-parser.ts; the other ports' FilterParser (Java codegen-spring/.../runtime/FilterParser.java, Python codegen/runtime/filter_parser.py, C# MetaObjects.Codegen/Runtime/FilterParser.cs, Kotlin controller) have no equivalent.

Current posture

MetaObjects.Codegen/Runtime/FilterParser.cs KNOWN_GAPS already explicitly defers filter[or]/filter[and] as "out of scope of FR-009 … defer until real consumer demand." So the de-facto project posture is already TS-only until demand.

Decision needed

• Option A — TS-only by design (recommended default). Document the divergence in docs/features/api-contract.md (a "TS-only filter extensions" note) so adopters know these are not part of the cross-port contract. No code change.
• Option B — implement cross-port. Port the wanted feature(s) to the other 4 ports + add api-contract conformance scenarios. Likely driven by real consumer demand for a specific feature (e.g. ?search=), not all five at once.

Out of scope / already cross-port (for reference)

invalid_filter_field / invalid_filter_op / invalid_filter_value 400s are implemented in all 5 ports (field+op already gated by filter-invalid-field.yaml/filter-invalid-op.yaml; an invalid_filter_value scenario is a separate low-risk add). ERR_YAML_COERCION is already gated by the error-yaml-coerced-* fixtures.

Surfaced by the FR-033 wrap-up survey (PRs #30, #31).

[dmealing]

Resolved as Option A (TS-only by design) — already documented. docs/features/api-contract.md has a "TS-only filter extensions (not part of the cross-port contract)" section covering all five audited behaviors: ?search=, filter[or]/filter[and] combinators, leading-wildcard gating, filter nesting-depth cap, and the in-list size cap (flagged as the one consistency/safety item worth unifying cross-port regardless of feature demand). Adopters are told not to assume these on a non-TS backend. Closing as documented; cross-port implementation (Option B) remains demand-driven if a specific consumer needs one.