fix(rfc): own scan state per execution, lease connection slots, pin credentials

[jrosskopf]

Implements the plan from a five-persona crew investigation of erpl's RFC connection
lifecycle. The investigation overturned my own diagnosis, and the earlier review's: the
defect is bind-data ownership of mutable scan state, not connection churn. The
churn-based fix I had proposed is not in this PR, and the previous review's destructor
fix was retracted by its own authors as a no-op.

1. A re-scanned sap_read_table returned nothing, silently

PREPARE q AS SELECT count(*) FROM sap_read_table('SFLIGHT');
EXECUTE q;   -- 94
EXECUTE q;   --  0     <- no error

Column state machines lived on bind data, which DuckDB reuses across executions of a
bound plan, so the second scan resumed from an exhausted cursor. Any re-scanned plan
hits it: a prepared statement, a nested-loop join, an un-materialised CTE referenced
twice. This is in released erpl and returns wrong data rather than failing.

Serial scans now build their machines in the global state, which is created per
execution — the pattern the partitioned path already used, which is why PARTITIONS was
never affected and serves as the non-regression guard.

Step() and HasMoreResults() now take the machine set explicitly rather than reading
it from bind data. That is what found three more sites with the same defect —
sap_show_tables, sap_odp_show_subscriptions, and the table lister behind ATTACH. A
convenience overload would have left all three broken and the compiler silent.

2. The persistent-connection budget was spent permanently

TryReservePersistentSlot was a monotonic fetch_add on bind data that never released a
slot — not on a failed reservation, not when the connection was dropped. Once cap
attempts had been made, no machine won a slot again, including in later executions.
Slots are now leased: returned on failure, returned in InvalidateCachedConnection,
reset per execution.

3. A long scan could follow a secret replaced underneath it

OpenNewConnection re-resolved the DuckDB secret on every open. Replacing the secret
mid-query sent later windows of the same scan to a different SAP system — no error, and
nothing in the result to show it. Credentials are now resolved once per execution.

Observability: sap_rfc_live_connections()

Also sap_rfc_connections_opened() / _closed(). Every open connection is a session and
a work-process reservation on the SAP system, and client-side timing reveals nothing
when one is never released — the entire cost lands on the source system. Between
queries the live count must be 0.

This existed to make the fix testable. Measured before it: disabling the connection cache
entirely (erpl_rfc_max_persistent_connections = 0) changed wall clock by nothing at
partitions=8 (1.52s vs 1.49s) or partitions=1 (44.9s vs 42.3s) — which is why a
timing-based test would have proved nothing here.

Tests, written red first

sap_read_table_rescan.test — prepared statement executed repeatedly; an
order-insensitive content checksum (a count-only assertion passes while the rows
differ); one statement scanning the function twice; an early LIMIT that leaves the
machines mid-table rather than exhausted; and the partitioned path as non-regression.

sap_rfc_connection_release.test — the live count returns to baseline after a plain
scan, a partitioned scan, an early LIMIT, a failing scan, and three executions of
one prepared plan. Plus a guard that the counters actually move, so a stub returning 0
would fail every other assertion in the file.

Asserted as a delta against a baseline taken in the same session, not an absolute, so
the file does not depend on what ran before it.

suite	result
offline: partition / batching / tracing	11/11, 6/6, 1/1
RFC nwrfc	pass, 0 failures, 0 known gaps
RFC proto	pass, 0 failures, 0 known gaps
ODP nwrfc	pass, 0 failures, 0 known gaps
ODP proto	pass, 0 failures, 0 known gaps
BICS nwrfc	pass, 0 failures, 0 known gaps

Bumps the odp gitlink for DataZooDE/erpl-odp#11, which carries the matching
sap_odp_show_subscriptions fix.

Not in this PR

The partitioned scan still invalidates its connection at every window boundary. With
slots now leased that is accounted correctly, but whether the connection should survive a
window is a separate question — and the measurement above says it is not a throughput
question. It wants its own change and its own logon-rate evidence.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}