Infrastructure abstraction layer: local/in-memory and production implementations via compile-time features

## Objective

Introduce a consistent infrastructure abstraction pattern across all external service dependencies so that:

1. Every external service (database, cache, certificate store, DNS provider, secrets manager, signing backend) has a trait-based abstraction.
2. Each abstraction has at least two implementations selectable via compile-time Cargo features:
- A **local/in-memory** implementation suitable for development and CI (no external services needed).
- A **production** implementation backed by real infrastructure (Postgres, Redis, AWS S3, Route53, etc.).
3. Feature flags are used for **compile-time** selection, not runtime configuration. Mutually exclusive features enforce correct selection.

This is a foundational architectural ticket that must be completed before or alongside:
- [#143](https://github.com/adorsys/status-list-server/issues/143) (configurable database backends)
- [Pluggable cache backend](https://github.com/adorsys/status-list-server/issues/166) (memory/Redis cache)
- [#159](https://github.com/adorsys/status-list-server/issues/159) (certificate provisioning strategies)
- [#162](https://github.com/adorsys/status-list-server/issues/162) (multiple DNS providers)

## Current State

The codebase currently has hard-wired dependencies on:
- PostgreSQL via sqlx/SeaORM (`src/database/`)
- Redis for certificate cache (`src/utils/cert_manager/`)
- AWS S3 for certificate storage (`src/utils/cert_manager/storage/`)
- AWS Secrets Manager for signing key storage
- AWS Route53 for DNS-01 challenges

There are no in-memory/local fallbacks for any of these. Tests rely heavily on Docker (testcontainers) even for simple development scenarios.

## Deliverables

- [x] Audit all external service dependencies in the codebase and categorize them.
- [x] Define traits for each service category:
- `StorageBackend` (S3 / local filesystem / in-memory)
- `SecretsBackend` (AWS Secrets Manager / env vars / in-memory)
- `DnsProvider` (Route53 / Cloudflare / Pebble / mock)
- `KeyStore` (certificate signing keys — AWS / filesystem / in-memory)
- [x] Implement local/in-memory versions:
- `FsStorageBackend` — reads/writes to a local directory (for Docker Compose / dev).
- `EnvSecretsBackend` — reads from environment variables or a `.env.secrets` file.
- `MockDnsProvider` — records requests, always returns success. For CI and unit tests.
- `InMemoryKeyStore` — generates/holds keys in memory. For CI.
- [x] Feature flags in `Cargo.toml`:
- Default features (`dev`): local storage, env secrets, mock DNS, in-memory key store.
- Production features (`prod`): S3 storage, AWS secrets, Route53 DNS, AWS key store.
- Mutually exclusive pairs with compile errors on conflict.
- [x] Update `src/utils/state.rs` (AppState construction) to use feature-gated service resolution.
- [x] Update `docker-compose.yml` to work with local implementations by default.
- [x] Update CI to use local implementations so PostgreSQL/Redis service containers are optional for tests.
- [x] Ensure existing testcontainers-based tests still pass when the `prod` feature is used.
- [x] Document the abstraction pattern, trait naming convention, and how to add new backends in `docs/architecture.md`.

## Acceptance Criteria

- `cargo build --features dev` compiles with zero external service dependencies (no Postgres, no Redis, no AWS).
- `cargo build --features prod` compiles with all production dependencies.
- Enabling conflicting features produces a compile error with a clear message.
- All existing tests pass under both feature sets.
- New developers can run the server locally without Docker.
- The pattern is reusable: adding a new backend (e.g., Cloudflare DNS) involves only implementing a trait and adding a feature flag.

## References

- Architecture review: `docs/architecture-review.md` (overall dependency on AWS-only services)
- [#139](https://github.com/adorsys/status-list-server/issues/139) (least-privilege, caching, infrastructure discussion)
- Related: [#143](https://github.com/adorsys/status-list-server/issues/143), [#159](https://github.com/adorsys/status-list-server/issues/159), [#162](https://github.com/adorsys/status-list-server/issues/162)