fix(entities): make JSON numeric comparison backend-safe across SQL backends

[maxdubrinsky]

Summary

Continues AIRCORE-749, addressing items (2), (4), and (5). Stacked on #264 (item (1), $like) — review/merge that first; this branches from it.

All three are verified against real PostgreSQL + SQLite (the parity suite now runs both).

(2) Numeric comparison no longer 500s on PostgreSQL (the prod crash)

_cast_json_to_numeric emitted an unconditional CAST(... AS FLOAT). On PostgreSQL a $gt/$lt against a JSON field that holds non-numeric text raised invalid input syntax for type double precision — a latent production 500 reachable from the user-facing filter param — while SQLite silently coerced the text to 0.0 (wrong matches). New dialect-dispatched _JsonNumeric construct casts only when the JSON value is actually a number (json_type IN ('integer','real') on SQLite; json_typeof = 'number' on PostgreSQL), yielding SQL NULL (no match) for non-numeric / null / absent on both backends — matching InMemoryFilterRepository's ordered-comparison contract. The path is bound as a parameter, so emitted SQL text is constant (cache-safe).

(4) $eq None matches absent JSON keys on PostgreSQL too

cast(col, String) == 'null' matched absent keys only on SQLite (which renders absent as the text 'null'); on PostgreSQL an absent key is SQL NULL, so absent keys did not match $eq None. Added an IS NULL test so both backends match absent + explicit-null, as the in-memory backend does.

(5) Postgres parity leg

test_filter_matches_sql_parity.py now runs every case against SQLite and PostgreSQL (testcontainers, skipped when Docker is unavailable) plus in-memory — the SQLite-only leg is exactly what let these divergences hide. New cases pin the numeric-guard and absent-key behavior.

Verification

• Full entities unit suite: 323 passed (parity now 64 = 32 cases × 2 backends).
• Pre-fix proof against real Postgres: the numeric cases raise psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type double precision: "notnum", SQLite diverges (SQL=[1,2,3,4,…] vs [1]), and eq_data_k_none gives SQL=[1] vs [1,2,4,5,…]. All pass after the change on both backends.
• ruff + ty clean.

AIRCORE-749 item (3): won't-fix

Boolean text rendering under $like/$in/$nin (only $eq/$ne normalize JSON booleans across backends) is intentionally not addressed. Boolean filtering in practice uses $eq/$ne, which work correctly; the cross-backend divergence only exists for degenerate shapes ($like on a boolean — substring-matching a bool; $in [True] which is equivalent to $eq True) that have no real use case. The divergence stays documented in InMemoryFilterRepository's docstring and the parity suite's module docstring; no shared-filter-layer code is added for it.