test(mongodb): assert graceful backend errors on an unreachable server

[mauripunzueta]

Summary

Adds a reusable error-handling test pattern for the MongoDB backend: point a MongoBackend at an unreachable address and assert its operations surface a StorageError::Backend — rather than panicking, hanging, or returning a misleading result (e.g. a read that reports "not found" when it never actually reached the server).

This is the reusable, team-wide kind of test requested: it validates the backend's error-handling contract across operations and is a template future tests copy to drive any Mongo error path.

What it adds

• unreachable_backend() — builds a backend at 127.0.0.1:1 (connection refused, deterministic) with a short connect timeout. Construction is lazy, so new never connects; the error surfaces when an operation runs.
• assert_backend_error() — asserts a storage Result is Err(StorageError::Backend(_)), the uniform way an unreachable server surfaces.
• mongodb_integration_unreachable_server_surfaces_backend_error — drives read / count / create concurrently (so the driver's bounded server-selection timeout is paid once) and asserts each fails with a backend error.

Unlike the rest of the suite, this needs no server at all — it always runs in CI and locally, no Docker required.

Stacking

Base is test/mongo-suite-testcontainers (PR #209), not main, per plan — this builds on the Mongo test work and touches the same file, so stacking avoids conflicts. It will be retargeted to main (and rebased) once #209 lands.

Validation note

Because this PR targets a non-main base, the HFS CI workflow does not run on it (CI is gated to base=main). The addition was hand-verified against the exact ResourceStorage signatures (create/read/count) and MongoBackendConfig fields, and is rustfmt-clean, but it is not yet machine-validated. It will get full CI once #209 merges and this rebases onto main — or on request I can run a one-off validation by temporarily retargeting it to main.