Superuser-only ORE SQL coverage suite for the deferred *_ord_ore domains

[coderdan]

The block-ORE domains (bigint_ord_ore, date_ord_ore, double_ord_ore,
integer_ord_ore, numeric_ord_ore, real_ord_ore, smallint_ord_ore,
timestamp_ord_ore, text_ord_ore) are marked deferred in the v3 domain
matrix (packages/test-kit/src/catalog.ts) and skipped by the family driver: the
ORE operator class/family is superuser-only and self-skips on
insufficient_privilege, so it is absent on managed Postgres and Supabase, and
the bundle disables the ORE-backed domains it cannot support. As a result these
domains currently have no live SQL coverage — the integration matrix cannot
exercise them on the CI service Postgres.

Goal

A dedicated follow-up suite that runs in an environment where the ORE operator
class is installed (a superuser Postgres with the full bundle), exercising the
eql_v3.* ORE ordering/comparison SQL operators against the *_ord_ore domains
directly — the coverage the managed-Postgres matrix deliberately defers.

Scope

• Provision a superuser Postgres variant (compose file) with the ORE opclass present.
• Flip the ORE domains from deferred to covered in that suite's context only
  (the managed-Postgres matrix keeps deferring them), or add a parallel ORE matrix.
• Assert ORE ordering/range correctness (ob term) end to end, mirroring how the
  OPE *_ord domains are covered today.
• Keep it off the default integration jobs (which run against managed/Supabase
  Postgres without the opclass); gate it to the superuser variant.

Notes

• docs/eql-v3-ord-term-ordering-defect.md explains why ORE is superuser-only and
  why OPE (*_ord) is the managed-Postgres path.
• The matrix already documents the deferral with a per-row reason; this suite is
  what "un-defers" ORE where the opclass exists.

Context: session follow-up on the 1.0 candidate (#535); the recurring _ord_ore
live-coverage gap noted while building the integration harness (#616).