Table-check IR, names, and canonical renderer

[0x054]

Part of #339

Parent

#339 — table checks (named multi-column CHECK), auto-migrated

What to build

SchemaIR can carry a table check: a canonical name ck_<table>_<suffix> plus a structured check predicate (not user SQL). One renderer in the shared lowering layer produces the CHECK body. Cargo tests pin names (including 63-char truncation), and the IS NULL / OR body SQL that Transfer needs.

No Python Check API, no CREATE TABLE wiring, no auto-migrate — this is the contract later tickets compile into and emit from.

Acceptance criteria

• A table check in SchemaIR has a canonical name ck_<table>_<suffix> with the same 63-character truncation rule as column checks (…_ck).
• The check predicate is structured (and / or / not / is-null / is-not-null at minimum). The renderer does not accept a raw SQL string as the body.
• Rendering IS NULL / OR combinations is byte-stable; cargo tests pin the exact SQL.
• Column checks (Field(db_check=True) → col IN (...)) still render identically — this ticket must not change their body or ck_<table>_<col> names.
• Python can consume the name helper and renderer over the existing FFI naming seam (same pattern as column-check names).

Blocked by

None — can start immediately.

[0x054]

Landed on feat/table-checks via #348 (squash). Parent #339 stays open until the remaining slices land.