mealie: reconcile BASE_URL with the domain actually chosen at the Caddy prompt

Confirmed live: install_mealie() pre-computes BASE_URL as
recipes<suffix>.$SITE_DOMAIN before ever asking about Caddy, then
configure_caddy_for_service() separately prompts for a domain — which the
user can freely override (e.g. typing mealie.mydomain.com instead of
accepting the recipes.mydomain.com default). Nothing fed that choice back
into BASE_URL, so it stayed stale. Since BASE_URL is exactly what
_mealie_offer_authelia_oidc() registers as the OIDC redirect URI, this
produced Authelia's "redirect_uri does not match any of the OAuth 2.0
Client's pre-registered redirect_uris" — Caddy and DNS were both correctly
pointed at the new domain, but the client Authelia had on file still said
the old one.

Added CADDY_SERVICE_DOMAIN as a new configure_caddy_for_service() out-param
(lib/common.sh) — the same out-param convention as the existing
CADDY_SERVICE_CONFIGURED/CADDY_SERVICE_MODE, set right after the domain
prompt is accepted. install_mealie() now reconciles BASE_URL against it
immediately after the Caddy call, before the Authelia OIDC step reads
BASE_URL back out of .env. ActualBudget's equivalent OIDC offer asks for
its own domain fresh each time rather than reading a pre-computed BASE_URL,
so it isn't affected by this class of bug and needs no equivalent fix.

Verified the reconciliation logic in isolation against a synthetic .env.

services/mealie.sh

@@ -442,6 +442,22 @@ MEALIE_ENV
 
     configure_caddy_for_service "Mealie${INSTANCE_SUFFIX:+ ($INSTANCE_SUFFIX)}" "${CONTAINER}:9000" "recipes${INSTANCE_SUFFIX:+-$INSTANCE_SUFFIX}"
 
+    # The domain typed at that prompt can differ from the recipes.<domain>
+    # default BASE_URL was already set to above (e.g. the user overrides it
+    # with a different subdomain). Reconcile BASE_URL to match whatever
+    # Caddy actually ended up fronting, since BASE_URL is what gets
+    # registered as the OIDC redirect URI just below — a stale BASE_URL
+    # there means Authelia rejects every login with "redirect_uri does not
+    # match any of the OAuth 2.0 Client's pre-registered redirect_uris" even
+    # though Caddy and DNS both point at the right place. Confirmed live:
+    # this is exactly what happened when the Caddy prompt was answered with
+    # a different subdomain than the auto-generated default.
+    if [ "$CADDY_SERVICE_CONFIGURED" = true ] && [ -n "$CADDY_SERVICE_DOMAIN" ] && [ "$MEALIE_BASE_URL" != "https://${CADDY_SERVICE_DOMAIN}" ]; then
+        MEALIE_BASE_URL="https://${CADDY_SERVICE_DOMAIN}"
+        sed -i "s#^BASE_URL=.*#BASE_URL=${MEALIE_BASE_URL}#" .env
+        log_info "BASE_URL updated to match the domain just configured: $MEALIE_BASE_URL"
+    fi
+
     declare -F _mealie_offer_authelia_oidc >/dev/null 2>&1 && _mealie_offer_authelia_oidc "$MEALIE_DIR" "$CONTAINER"
 
     write_readme "$MEALIE_DIR" << MD