Fix the Oracle queue Uri identity round-trip, and finish GH-3808 (GH-3820)

[jeremydmiller]

Closes #3820.

The handoff called the casing mismatch under #3808 "the real bug to chase." It is — and it is a
product bug, not a test quirk. It reproduces in 43ms with no Oracle container.

The defect

OracleTransport.findEndpointByUri looked its queue up with a bare Queues[uri.Host]:

protected override OracleQueue findEndpointByUri(Uri uri)
{
    var queueName = uri.Host;
    return Queues[queueName];
}

That is correct for the two transports it was copied from — and wrong for this one:

Transport	SanitizeIdentifier	System.Uri authority	Round-trips?
Postgres	ToLowerInvariant	lower-cased	✅
SQL Server	ToLowerInvariant	lower-cased	✅
Oracle	ToUpperInvariant	lower-cased	❌

System.Uri normalises the authority to lower case, so an upper-cased Oracle queue name never came
back out of its own Uri. Queues is a LightweightCache, so the miss didn't throw — it silently
created a second OracleQueue over the same physical queue tables.

This is reachable from ordinary user code: ToOracleQueue("name") ends with
publishing.To(queue.Uri), which round-trips the endpoint through its own Uri. Oracle is the only
transport in the repo whose SanitizeIdentifier upper-cases, so it is the only one affected —
checked across every SanitizeIdentifier override.

The fix

Queues[SanitizeIdentifier(uri.Host)]. SanitizeIdentifier rather than MaybeCorrectName
deliberately: the host segment already carries any IdentifierPrefix, which MaybeCorrectName would
prepend a second time. The correction is idempotent, so a Uri built from an already-corrected name is
unaffected.

Two new tests, no database required, both red on main:

transport.GetOrCreateEndpoint(queue.Uri) should be same as
  OracleQueue (22550079) but was OracleQueue (55400036)

The other two uri.Host reads in the Oracle transport are Guid.Parse on control-endpoint node ids,
which is case-insensitive — not affected.

What that unlocks

clear_all_wolverine_storage was the sole provider in ClearAllWolverineStorageCompliance attaching
a listener, against the base class's explicit instruction, purely to work around the duplicate
endpoint. It can now go subscriber-only like Postgres, SQL Server, MySql and Sqlite.

That also removes the cause of the ORA-00054 the handoff flagged. The listener was the only thing
holding a TM/DML lock on the queue table; #3808 made that lock reachable by pointing the DROP at a
schema whose tables actually exist. So the contention is gone rather than retried around.

The unreachable handler (my defect from #3808)

catch (OracleException e) when (e.Number == 54 && attempt < maxAttempts)

On the final attempt the guard is false, the raw OracleException escapes the loop, and the
descriptive InvalidOperationException below it is dead code — it never ran once, which is exactly
what the CI error demonstrated. ORA-54 is now caught unconditionally, with the last one carried out as
the inner exception so the descriptive throw finally names the underlying Oracle error too.

The retry itself stays as a belt-and-braces guard — a host from a prior class in the collection can
still be tearing connections down — and the doc comment no longer claims a listener this class no
longer has.

Verification

• Full OracleTests suite: 115 passed, 0 failed (against a live gvenzl/oracle-free:23-slim)
• clear_all_wolverine_storage + the new tests: 7 passed in 6s, no retry (was 1 retry/run)
• New tests confirmed red before the fix, green after
• Full wolverine.slnx Release build clean, 0 warnings

🤖 Generated with Claude Code

https://claude.ai/code/session_01WHAuhdWS3XeAk16swV9G8m