ODP delta suite: the cursor-hygiene assertion can only ever judge the previous run

[jrosskopf]

sap_odp_read_delta_negative.test fails on every run of the ODP suite against a
system that has run the suite before. It is the single failure standing between
the ODP suite and green, on both backends (23/24).

The assertion cannot pass

odp/test/sql/sap_odp_read_delta_negative.test:79 asserts no ERPL_TEST_*
delta cursor is left open, listing subscribers including
ERPL_TEST_SMOKE_001, ERPL_TEST_RESUME_001 and ERPL_TEST_RECOVER_001.

Tests run in alphabetical order:

sap_odp_read_delta_columns_filters
sap_odp_read_delta_independence
sap_odp_read_delta_negative        <-- asserts here
sap_odp_read_delta_recover         <-- creates ERPL_TEST_RECOVER_001
sap_odp_read_delta_resume          <-- creates ERPL_TEST_RESUME_001
sap_odp_read_delta_smoke           <-- creates ERPL_TEST_SMOKE_001

The assertion runs before the tests that create three of the subscribers it
checks. It can therefore only ever observe the previous run's residue, never
its own. On a fresh system it passes vacuously; on any system that has run the
suite once it fails regardless of whether the code is correct.

The test's header states the premise "Each delta test self-cleans, so the only
expected residue is closed cursors" — but sap_odp_read_delta_recover.test
contains zero sap_odp_close_delta_cursor calls.

Evidence it is not stale ad-hoc residue

request_date on the open cursors matches the most recent full suite run
(e.g. 2026-09-01 06:10:16-06:10:34, six cursors within 18 seconds — the
suite's own delta tests). Each run leaves exactly one open cursor per delta
subscriber alongside 11-22 closed ones.

I had previously written this off as residue from my own ad-hoc runs. The
timestamps show that was wrong.

Not fixable by closing the cursors

The cursors are stuck server-side: calling RODPS_REPL_ODP_CLOSE directly with
the correct pointer does not close them (see #134). The test's own header already
documents that only a SAP server restart clears them.

A restart is not an acceptable remedy here — a4h is shared infrastructure and
restarting it destroys the SNC/wsRFC certificate trust the erpl-proto backend
depends on.

Suggested fix

Make the assertion answerable:

• scope it to cursors this run created (e.g. filter on request_date at or
  after a timestamp captured at the start of the file), rather than to a
  hard-coded subscriber list spanning tests that have not run yet; and
• give sap_odp_read_delta_recover.test the close call its siblings have, so the
  stated "each delta test self-cleans" premise is actually true.

Either alone leaves the ordering problem or the leak in place; both together make
the suite legitimately 24/24 instead of an expected failure that has to be
explained on every run.

[jrosskopf]

Root cause is largely #134, not test sloppiness: LookupCursor returns the first (proc, queue) match, which is a closed history row, so RODPS_REPL_ODP_CLOSE is never called. sap_odp_read_delta_smoke.test calls the close pragma three times and still leaks. See the correction comment on #134. The ordering flaw described here is real and still worth fixing, but it is the second-order problem.