feat(mongodb): make transaction read concern configurable

[xgerman]

Problem

The MongoDB storage backend hardcodes readConcern: snapshot on every multi-document transaction it opens (conditional writes, TransactWriteItems, TransactGetItems, idempotency-token checks). Real MongoDB (7.0+) supports this and it's the strongest available isolation level, but some MongoDB-wire-compatible servers do not implement it.

Concretely, DocumentDB (a Postgres-based MongoDB-API-compatible database) rejects transactions started with readConcern: snapshot with Error code 115 (CommandNotSupported), which makes the mongodb backend unusable against it beyond CreateTable.

Change

Adds storage.mongodb.transaction_read_concern (default: "snapshot", preserving current behavior) so operators can set "majority" or "local" to run against backends that don't implement snapshot reads, trading off snapshot isolation for compatibility. Also updates the MongoDB backend design doc (docs/design/13-storage-mongodb.md) to describe the new setting.

As a side effect, this widens ServerComponentsFactory's StorageConfig trait-object bound from an elided reference lifetime to 'static. StorageConfig::as_any()'s downcast is already documented as the intended mechanism for backend-specific settings like this one, but Any::downcast_ref requires the pointee to be provably 'static — an unannotated &dyn StorageConfig doesn't satisfy that, so the downcast wouldn't compile without this change. All existing callers already own 'static data (Box<dyn StorageConfig>), so this is not a breaking change for callers.

Validation

• cargo build --workspace, cargo test (all touched crates pass), cargo clippy --workspace -- -D warnings clean.
• Verified end-to-end against a real DocumentDB 0.116.0 instance (built from source to pick up an unrelated upstream Postgres-extension fix) with transaction_read_concern = "majority": CreateTable, PutItem, GetItem, and DeleteTable all succeeded via the DynamoDB API surface.
• Default behavior (real MongoDB, transaction_read_concern unset) is unchanged — still snapshot.

Trade-offs

Running with majority/local instead of snapshot weakens isolation between concurrent transactions on backends that use this setting — concurrent transactions may observe a less consistent view of the data than under true snapshot reads. This is called out in both the sample config and the design doc.