test: the SQE catalog workload through Connection, both directions against the oracle (013/Req-7)

[dpsiderius]

Description

Spec 013 Requirement 7's acceptance workload — the SQE Iceberg catalog's real
statements — is not driven through sqlite_rs::api. It exists in two halves
that do not meet:

• tests/corpus/api_oracle_test.rs diffs the facade against the pinned
  oracle, but on a synthetic workload (CREATE TABLE t(a, b, c)).
• tests/corpus/consumer_sqe_test.rs (test: SQE's catalog as a consumer fixture family, and four ratchets it exposed (013/Req-6) #704) diffs the verbatim catalog
  statements against the oracle, but through the CLI binary, which cannot
  bind parameters.

So nothing runs the consumer's parameterised statements through the API that
the consumer actually calls.

Why this is the ticket that matters

This gap is not hypothetical, and its cost is already measured. The SQE team
ran their catalog through sqlite_rs::api on their side and found four
defects in one afternoon that our entire corpus had not:

• bind parameters numbered in the wrong order on UPDATE (fixed — swapped
  values, Ok(0), and the rows-affected conflict signal made useless)
• placeholder counting collapsing on a covering-index plan (same fix)
• rowid not selectable (bug: rowid is not selectable in a projection — resolves in WHERE, unknown in the result list #708)
• sqlite_master not queryable (bug: SELECT ... FROM sqlite_master does not compile — the catalog is invisible to the SELECT path #707)

The first two were invisible to us for a specific and instructive reason:
every parameter test in this repository is written with ?1/?2, the form
our own code emits. Drivers emit bare ?. Our parameterised-write oracle test
was comparing our dialect against itself.

A test that drives a real consumer's real statements through the public API is
the thing that catches this class. That is what this ticket builds.

Scope

tests/parity/ — the declared [[test]] parity target, which is where the
consumer's own proposal asked for it and where oracle-diff-by-V-block lives:

• Create the database through Connection, run the catalog workload with
  bound parameters, and diff both tables against the pinned oracle with
  SELECT * ... ORDER BY 1,2,3.
• Then the reverse: stock sqlite3 writes the same workload, Connection
  reads it back identically. This is the "existing embedded sqe.db files
  keep working" direction.
• integrity_check = ok in both directions.
• The optimistic-concurrency UPDATE must report 0 on a stale expected
  metadata_location and 1 on a match — the assertion the consumer's
  conflict detection is built on.
• Every placeholder written as bare ?, not ?NNN. This is load-bearing: it
  is the form the consumer emits and the form that hid two defects.

Fixtures

The consumer has offered two real files — a first-run empty catalog and a
populated one (one namespace, one table after two commits, so both
metadata_location and previous_metadata_location are set, catalog_name
= sqe-embedded). They have not arrived yet and are not in the repo;
tests/corpus/fixtures/consumers/sqe/*.sql is a reconstruction from the DDL,
not a database they produced.

Prefer their files for the reverse direction — a file we rebuilt from the
schema cannot prove "files your deployment already has keep working".

Blocked on, partially

The literal declared-composite-PRIMARY KEY DDL still needs #687 and
#697. Those are the #[ignore]d ratchets in #704. This ticket can land with
the consumer's named-unique-index workaround (their current production shape)
and un-#[ignore] the literal form when those close.

Acceptance Criteria

• tests/parity/ test creating the catalog through Connection, running
  the workload with bare ? parameters, and diffing both tables against
  the pinned 3.53.4 oracle
• Reverse direction: oracle writes, Connection reads back identically
• integrity_check = ok both ways
• The conditional UPDATE reports 0 on a stale location and 1 on a match
• Built on the consumer's own .db files where they cover the case
• Spec 013 Requirement 7's Implementation: line names which phase (7a
  workaround / 7b literal) each test discharges
• Requirement 7 stops being backed only by a CLI-driven test

Complexity

Estimate: medium
Reasoning: No new engine work — it is a test against two existing,
working paths. The size is in the fixtures and the diff harness: rendering our
rows the way the sqlite3 shell does for text comparison already exists in
api_oracle_test.rs and can be lifted, and the reverse direction needs the
oracle to build state our reader then walks. Bounded and mostly mechanical,
but it is ~12 statements each way with exact row and count assertions.

Refs: 013/Req-7, 013/Req-6, #704, #705, #687, #697