feat(bench): enable the eql_v3 OPE ordering scenario

Cargo.toml

@@ -17,13 +17,13 @@ rand = "0.8.5"
 # cipherstash-client + stack-profile ship from the same cipherstash-suite
 # workspace and must stay version-locked — cipherstash-client implements
 # `KeyProvider` for stack-profile's `ProfileStore`, so a source/version
-# mismatch produces two incompatible `ProfileStore` types. 0.38.0 keeps the
+# mismatch produces two incompatible `ProfileStore` types. 0.38.1 keeps the
 # EQL v2 wire payloads (`k`/`c`/`v`/`i`) byte-identical to the
 # 0.34.1-alpha.9 pre-release that EQL 2.3.0 targets — the eql wire formats
 # module is unchanged between the two — so the EQL release pin in
 # mise.toml's setup-db task stays at eql-2.3.0. Bump both together.
-cipherstash-client = { version = "=0.38.0", features = ["tokio"] }
-stack-profile = "=0.38.0"
+cipherstash-client = { version = "=0.38.1", features = ["tokio"] }
+stack-profile = "=0.38.1"
 # EQL v2.3 → v3 wire conversion (`from_v2`) + canonical v3 payload types.
 # Consumed as a path dependency off the EQL repo's `feat/eql-bindings-from-v2`
 # branch while the crate is unreleased.
@@ -91,6 +91,10 @@ path = "src/bin/encrypt_string_v3.rs"
 name = "encrypt_int_v3"
 path = "src/bin/encrypt_int_v3.rs"
 
+[[bin]]
+name = "encrypt_int_ope_v3"
+path = "src/bin/encrypt_int_ope_v3.rs"
+
 [[bin]]
 name = "encrypt_category_v3"
 path = "src/bin/encrypt_category_v3.rs"

README.md

@@ -119,9 +119,10 @@ WHERE eql_v3.eq_term(value) = eql_v3.eq_term($1::eql_v3.text_search)
 | v2 table | v3 twin | Domain | Notes |
 |---|---|---|---|
 | `string_encrypted` | `string_encrypted_v3` | `eql_v3.text_search` | Only single-column v3 domain serving both EXACT (hm) and MATCH (bf); requires an extra `ob` ORE term the v2 string ingest doesn't encrypt — `encrypt_string_v3` throughput is therefore not directly comparable to `encrypt_string`. |
-| `integer_encrypted` | `integer_encrypted_v3` | `eql_v3.int4_ord_ore` | v2 encrypts `i32` (int4). |
+| `integer_encrypted` | `integer_encrypted_v3` | `eql_v3.integer_ord_ore` | v2 encrypts `i32` (int4). |
+| *(none — v3-only)* | `integer_ope_encrypted_v3` | `eql_v3.integer_ord_ope` | OPE-CLLW ordering (wire key `op`); requires cipherstash-client >= 0.38.1. |
 | `category_encrypted` | `category_encrypted_v3` | `eql_v3.text_eq` | |
-| `combo_encrypted` | `combo_encrypted_v3` | `text_match` / `int4_ord_ore` / `text_eq` | Per-column capability match. |
+| `combo_encrypted` | `combo_encrypted_v3` | `text_match` / `integer_ord_ore` / `text_eq` | Per-column capability match. |
 | `json_ste_vec_small_encrypted` | `json_ste_vec_small_encrypted_v3` | `eql_v3.json` | SteVec document domain. |
 | plaintext baselines | *(shared)* | — | Version-independent; not duplicated. |
 
@@ -138,10 +139,13 @@ WHERE eql_v3.eq_term(value) = eql_v3.eq_term($1::eql_v3.text_search)
   `GIN ((eql_v3.to_ste_vec_query(value))::jsonb jsonb_path_ops)` index);
   `field_eq/bare` becomes index-capable (the v3 `->` is inlinable SQL,
   unlike v2's plpgsql).
-- **ORE (OPE)**: the `eql_v3.*_ord_ope` domains (OPE-CLLW ordering, wire
-  key `op`) are scaffolded but **disabled** — cipherstash-client 0.38.0
-  does not emit `op` (CIP-3280 unreleased). See the TODOs in
-  `sql/schema-v3.sql` and `benches/ore_v3.rs`.
+- **ORE (OPE)**: the ORE_V3 family adds `ope_*` scenarios against
+  `integer_ope_encrypted_v3` (`eql_v3.integer_ord_ope` — OPE-CLLW ordering,
+  wire key `op`, extractor `eql_v3.ord_ope_term`, native bytea comparison
+  over a `btree (eql_v3.ord_ope_term(value))` index). Requires
+  cipherstash-client >= 0.38.1, which emits the scalar `op` term
+  (CIP-3280). The `ope_*` scenarios share thresholds with their ORE twins
+  for a direct ORE-vs-OPE comparison.
 - A dedicated **conversion-overhead** ingest family
   (`convert_overhead_encrypt_only` vs `convert_overhead_encrypt_convert`)
   quantifies the pure `from_v2` cost: identical encrypt workloads, no

benches/combo_v3.rs

@@ -1,6 +1,6 @@
 //! EQL v3 twin of `benches/combo.rs` — composite-predicate scenarios over
 //! `combo_encrypted_v3_<N>` (name `eql_v3.text_match`, age
-//! `eql_v3.int4_ord_ore`, category `eql_v3.text_eq`).
+//! `eql_v3.integer_ord_ore`, category `eql_v3.text_eq`).
 //!
 //! The v2 scenarios filter with `name LIKE $1`; v3 removes LIKE, so every
 //! scenario filters with the bloom containment recipe instead: