fix(rdbms-inbox): align RavenDb and CosmosDb batch inbox with #2648 duplicate-envelope contract

[BlackChepo]

Summary

Follow-up to #2648, which made the Wolverine inbox robust against
broker-redelivered duplicate messages by having DurableReceiver's
batch path catch a typed DuplicateIncomingEnvelopeException and
fall back to the per-envelope path (where each envelope is
correctly classified as fresh or duplicate).

That change moved the contract from "any exception means the inbox
is unavailable, pause the listener" to "throw DuplicateIncoming- EnvelopeException for duplicates, anything else is a real failure."
The RDBMS providers (Postgres, SqlServer, MySql, Sqlite, Oracle)
were brought in line as part of #2648, but two non-RDBMS providers
were missed because they have their own StoreIncomingAsync(IReadOnlyList)
implementations:

RavenDb

StoreIncomingAsync(IReadOnlyList<Envelope>) already threw
DuplicateIncomingEnvelopeException for NonUniqueObjectException /
ConcurrencyException, but always populated Duplicates with
envelopes[0] regardless of which envelope actually collided.
With the new compliance assertion (Duplicates must contain exactly
the envelopes already in the inbox), this caused the per-envelope
fall-back to ack an innocent fresh envelope at the listener and let
the real duplicate slip into the handler.

Now uses a findDuplicatesAsync helper that probes ExistsAsync
per envelope and reports only the ids that actually exist. Falls
back to the full batch when no pre-existing match is found (e.g.
an intra-batch identity collision with no prior insert) so the
per-envelope retry path still has something to sort, and the
existing Raven-only throws on [envelope, envelope] override
keeps passing.

CosmosDb

StoreIncomingAsync(IReadOnlyList<Envelope>) silently swallowed
HTTP 409 with the comment "DurableReceiver will retry one at a
time" — true before #2648, no longer true after. Without a
thrown exception the batch returns successfully and every envelope
in the batch (including the duplicate) is routed to the handler,
re-introducing the double-execution that #2648 fixed.

Now collects the conflicting envelopes and throws
DuplicateIncomingEnvelopeException(duplicates) at the end of
the loop, so the rest of the batch still commits while the
duplicate goes through the per-envelope path. Same shape as the
Oracle fix in #2648.

Note: CosmosDb's message_store_compliance subclass is not
currently picked up by the build script's test-class discovery
(it inherits from MessageStoreCompliance without declaring
its own [Fact] methods, and DiscoverTestClasses only sees
classes with attribute hits in the file). The shared compliance
test added in #2648 therefore does not run on CosmosDb in CI
today — closing that discovery gap is out of scope here, but
the fix is in place for whenever it is.

Test plan

• RavenDb compliance suite (incl. the
  bulk_store_intra_batch_duplicate_reports_only_actual_duplicates
  assertion from fix(rdbms-inbox): discard duplicate Kafka messages instead of freezing the partition (#2639) #2648) runs green
• Existing RavenDb-specific
  bulk_store_with_intra_batch_duplicate_throws_DuplicateIncomingEnvelopeException
  override stays green
• CosmosDb build is clean; behavior verified by inspection
  against the Oracle fix in fix(rdbms-inbox): discard duplicate Kafka messages instead of freezing the partition (#2639) #2648 (CI does not currently exercise
  the compliance test on CosmosDb)