v3: jsonb_entry domain CHECK calls a non-inlinable SQL function (+19% on field_eq queries) — and the pattern is systemic #354

Problem

eql_v3.jsonb_entry's domain CHECK is CHECK (eql_v3_internal.is_valid_ste_vec_entry_payload(VALUE)) — a LANGUAGE sql function. Domain constraints are another context where SQL functions cannot be inlined, so every cast to jsonb_entry (e.g. the needle in every field_eq query) pays ~18 µs of SQL-function-executor overhead.

Measured: this single call is the entire v2→v3 regression on JSON/json/field_eq/functional (+19% across tiers; in-DB 0.011 → 0.029 ms/query, with eq_term costs identical between versions). v2's ste_vec_entry CHECK was an inline expression and cost nothing measurable.

Proposal

Inline the validation expression directly into the CHECK constraint (v2's approach — and the generated scalar domains already do this):

CHECK (
  jsonb_typeof(VALUE) = 'object'
  AND jsonb_typeof(VALUE -> 's') = 'string'
  AND jsonb_typeof(VALUE -> 'c') = 'string'
  AND ((jsonb_typeof(VALUE -> 'hm') = 'string' AND NOT (VALUE ? 'oc'))
    OR (jsonb_typeof(VALUE -> 'oc') = 'string' AND NOT (VALUE ? 'hm')))
)

The systemic angle

This is the third confirmed instance of the same pattern (with the two ore_block_256 helpers in the sibling issue): "LANGUAGE sql for inlineability" is v3's global strategy, and it is correct everywhere inlining happens — but quietly expensive in every context where it can't: domain CHECK constraints, btree operator-class support paths, and functions invoked from plpgsql. Recommend an audit of every LANGUAGE sql function reachable from those contexts.

Evidence

Attribution tables (track_functions, v2 vs v3 at 100k) and the constraint comparison: v3-regressions-report.md on cipherstash/benches#23 (JSON/field_eq section + Issue 4).