Make omsorgapp's backend URL runtime-configurable, use dedicated API subdomain

- omsorgapp now reads the omsorgCore URL from a runtime env-config.js
  generated by the container entrypoint from OMSORG_CORE_URL, instead of
  only baking it in at image build time - docker-compose.yml pulls
  pre-built images from the registry, so a build-time-only value couldn't
  be changed without a rebuild.
- docker-compose.yml: omsorgCore gets its own subdomain
  (core.omsorg-pflegedienste.de) rather than being proxied under the
  frontend's domain - omsorgWeb never needs browser-side access to it
  anyway (server-side cURL only), and a dedicated API host is more
  future-proof without being any less secure (backend still only bound to
  127.0.0.1). Includes the nginx server-block snippet needed for the new
  subdomain.
- Drop the now-unused OMSORG_CORE_PUBLIC_URL build-arg wiring from the
  Gitea Actions workflow.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docker-compose.yml

@@ -7,11 +7,36 @@ name: omsorg
 # nicht öffentlich lesbar sind. Über OMSORG_IMAGE_TAG lässt sich ein bestimmter Versions-Tag
 # pinnen (z.B. `OMSORG_IMAGE_TAG=v0.1.0 docker compose up -d`), Default ist `latest`.
 #
-# WICHTIG: omsorgapp bäckt die omsorgCore-URL (VITE_OMSORG_CORE_URL) zur BUILD-Zeit in den
-# JS-Bundle ein (siehe omsorgapp/src/api/config.js) - das passiert jetzt in der CI über die
-# Repo-Variable OMSORG_CORE_PUBLIC_URL, nicht mehr hier. omsorgweb.environment.OMSORG_CORE_URL
-# ist davon unabhängig und bleibt der interne Compose-Servicename, da PHP dort serverseitig per
-# cURL aufruft (kein Browser-Kontext), siehe omsorgWeb/docker/bootstrap-config.php.
+# omsorgCore bekommt eine eigene Subdomain (core.omsorg-pflegedienste.de), nicht denselben
+# Hostnamen wie omsorgapp - Begründung: omsorgWeb (beide mitarbeiter-app*-Apps) braucht ohnehin nie
+# Browser-Zugriff auf omsorgCore (PHP ruft serverseitig per cURL auf, siehe
+# omsorgWeb/docker/bootstrap-config.php/OMSORG_CORE_URL unten), nur omsorgapp tut das - eine eigene
+# Subdomain macht die API trotzdem unabhängig von omsorgapps Hosting adressierbar (künftige
+# Clients, Doku, Swagger) und ist nicht unsicherer als Pfad-basiertes Proxying: in beiden Fällen
+# ist omsorgCore nur über 127.0.0.1 erreichbar (Port-Mapping unten), nie direkt öffentlich.
+# Browser-seitiges Cross-Origin läuft über CORS + HttpOnly-Cookie mit credentials:"include" (siehe
+# omsorgCore/CLAUDE.md, Abschnitt "Auth-Flow") - dafür muss Cors__AllowedOrigins__0 unten exakt
+# der Origin von omsorgapp entsprechen (https://app.omsorg-pflegedienste.de).
+#
+# Nginx-Server-Block für die neue Subdomain (analog zum bestehenden app.omsorg-pflegedienste.de-
+# Block, eigenes Zertifikat z.B. per `certbot --nginx -d core.omsorg-pflegedienste.de`):
+#
+#   server {
+#       server_name core.omsorg-pflegedienste.de;
+#       location / {
+#           proxy_pass http://127.0.0.1:8080;
+#           proxy_http_version 1.1;
+#           proxy_set_header Host $host;
+#           proxy_set_header X-Real-IP $remote_addr;
+#           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+#           proxy_set_header X-Forwarded-Proto $scheme;
+#       }
+#       listen 443 ssl; # managed by Certbot
+#       ssl_certificate /etc/letsencrypt/live/core.omsorg-pflegedienste.de/fullchain.pem;
+#       ssl_certificate_key /etc/letsencrypt/live/core.omsorg-pflegedienste.de/privkey.pem;
+#       include /etc/letsencrypt/options-ssl-nginx.conf;
+#       ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
+#   }
 #
 # Alle persistenten Daten liegen bewusst als Bind-Mounts unter /root/data/ auf der Platte (keine
 # benannten Docker-Volumes) - vor dem ersten `docker compose up` einmalig anlegen:
@@ -49,16 +74,24 @@ services:
       ASPNETCORE_ENVIRONMENT: Development
       ConnectionStrings__OmsorgCore: "Host=postgres;Port=5432;Database=omsorg_core;Username=omsorg_core;Password=omsorg_core_dev_password"
       Jwt__Secret: "CHANGE_ME_LOCAL_DEV_SECRET_MIN_32_CHARS_LONG"
-      Cors__AllowedOrigins__0: "http://localhost:5173"
+      Cors__AllowedOrigins__0: "https://app.omsorg-pflegedienste.de"
     ports:
-      - "8080:8080"
+      # Nur auf dem Host erreichbar (für den Reverse-Proxy oben), nie auf der öffentlichen
+      # Schnittstelle - matcht das 127.0.0.1:5173-Muster im bestehenden Host-nginx.
+      - "127.0.0.1:8080:8080"
     volumes:
       - /root/data/omsorgcore/documents:/app/App_Data/documents
 
   omsorgapp:
     image: git.omsorg-pflegedienste.de/admin/omsorg/omsorgapp:${OMSORG_IMAGE_TAG:-latest}
+    environment:
+      # Vom BROWSER erreichbare Adresse von omsorgCore - der Container-Entrypoint schreibt das
+      # zur Laufzeit in env-config.js (siehe omsorgapp/docker-entrypoint.sh/src/api/config.js),
+      # kein Rebuild bei einer geänderten Backend-URL nötig.
+      OMSORG_CORE_URL: "https://core.omsorg-pflegedienste.de"
     ports:
-      - "5173:80"
+      # Nur auf dem Host, wie omsorgcore oben - der Host-nginx proxied bereits 127.0.0.1:5173.
+      - "127.0.0.1:5173:80"
     depends_on:
       - omsorgcore