Database setup for the Website service (#13)

This PR contains the work done to introduce a _Fluent_-based persistence layer for the Website service, selectable at runtime alongside the existing in-memory default, plus the local dev tooling and docs to support it.

To provide further details about the work:

* Persistence package
  * The `Driver` and `TLS` enumerations
  * The `Configuration` type
  * The `Service` factory that builds the  service
  * `PrepareDB` for migrations registration
  * The `Probe` for readiness checks.

* App integration
  *  Builds the driver, registers migrations, and attaches `Fluent` to the service lifecycle so it starts/stops with the HTTP server.
  * Migrate-on-boot is gated to the in-memory backend; MySQL/MariaDB is migrated out of band via --database-migrate so shared databases never race on startup.
  * The `ConfigReader+Properties` extension maps database.* config keys onto the driver.

* Library
  * Added database configuration constants.
  * The `HealthController` controller gains a readiness probe: `GET /health/ready` checks whether the database is reachable, separate from the existing liveness check.

* Others
  * Updated the `docker-compose` files to support a database service behind a database profile, and hardened for local development
  * New database targets on the `Makefile` file and overall documentation updated
  * Updated the `.env.local`, `Dockerfile`, and `README` files to document the persistence workflow, config keys, and local DB commands

Reviewed-on: rock-n-code/loud-amsterdam#13
Co-authored-by: Javier Cicchelli <javier@rock-n-code.com>
Co-committed-by: Javier Cicchelli <javier@rock-n-code.com>

Packages/Localization/Sources/Internal/Protocols/CatalogResolving.swift

@@ -0,0 +1,37 @@
+import Foundation
+
+/// A backend that resolves localized strings for an explicit locale and reports the languages it serves.
+///
+/// This is the seam that decouples ``Localize`` and ``LanguageList`` from *how* localizations are stored
+/// and resolved. The shipping implementation, ``StringCatalog``, reads a raw `.xcstrings` catalog so it
+/// behaves identically on Darwin and Linux. A future backend — for example one built on
+/// `String(localized:)` for a native Apple app that needs plural and device variations — can conform
+/// without changing any caller.
+///
+/// Resolution never fails: an implementation returns the key itself when it has no localization for it,
+/// mirroring Foundation's `String(localized:)`. This is the contract both a dictionary lookup and the
+/// native API can honour, since the native API cannot distinguish a missing key from a translation that
+/// happens to equal the key.
+protocol CatalogResolving: Sendable {
+
+    // MARK: Properties
+
+    /// The source (development) language, used as the final fallback when a locale has no localization.
+    var sourceLanguage: String { get }
+
+    /// Every language the backend can resolve strings for, including the source language.
+    var languages: Set<String> { get }
+
+    // MARK: Methods
+
+    /// Resolves a catalog key in the given locale.
+    /// - Parameters:
+    ///   - key: the catalog key to look up.
+    ///   - locale: the locale to resolve the key in.
+    /// - Returns: the localized string, falling back to the source language, then to the key itself.
+    func string(
+        for key: String,
+        in locale: Locale
+    ) -> String
+
+}