refactor(demo-gymburgdorf): drop DNS workarounds now backend can reach DMZ

The firewall now permits the backend subnet (172.16.19.0/24) to reach the
DMZ reverseproxy on 443, so server-to-server calls can use the public
FQDN over the reverseproxy instead of the previous workarounds:

- Remove the `*_extra_hosts` pins from nextcloud, opnform, bookstack and
  homarr; their OIDC discovery/issuer now uses the public auth.gymb.* FQDN
  (verified: discovery returns 200 with the public iss over the reverseproxy).
- Switch nextcloud OIDC discovery_url from auth.int.* to auth.gymb.*.
- Drop authentik_host_rewrite_domains and authentik_outpost_domains; point
  the LDAP outpost (both host_vars) at the public auth.gymb.* FQDN.
- Repoint the garage-webui ForwardAuth from the never-functional dedicated
  outpost FQDN to auth.gymb.*. The embedded outpost only serves the auth
  path when Host is a configured authentik_domain and matches the protected
  app via X-Forwarded-Host, so auth.gymb.* stays pinned to the application
  host on storage to bypass the reverseproxy's X-Forwarded-Host stripping.

The *.int.* names and their cert SANs are kept: the DMZ verifies the
backend cert (acme cert_mode) and connects by name, so they remain
structural to the DMZ->backend hop. The console.s3 DMZ route limitation
is pre-existing and tracked separately.

inventories/demo-gymburgdorf/host_vars/application/nextcloud.yml

@@ -62,25 +62,16 @@ nextcloud_s3_port: 443
 nextcloud_s3_ssl: true
 nextcloud_s3_usepath_style: true
 
-# OIDC server-to-server discovery / token / userinfo goes to
-# auth.int.gymb.souveredu.ch (LAN, RFC1918). Nextcloud's DnsPinMiddleware
-# would otherwise block that as "local server access".
+# OIDC discovery/token/userinfo and the S3 backend both target FQDNs
+# that resolve to RFC1918 addresses (auth.gymb.* via the reverseproxy,
+# s3.int.* directly), which Nextcloud's DnsPinMiddleware would otherwise
+# block as "local server access".
 nextcloud_allow_local_remote_servers: true
 
 # Share the LDAP docker network with the authentik LDAP outpost
 nextcloud_extra_networks:
   - ldap
 
-# Pin the public authentik FQDN to the application host so server-to-server
-# OIDC traffic (token, userinfo, jwks — endpoints the discovery doc lists
-# under auth.gymb.* even when discovery itself is fetched via auth.int.*)
-# stays in the LAN. Without this, curl in the PHP container would hit the
-# public IP and time out in the DMZ (no hairpin-NAT). The DnsPin middleware
-# only honours /etc/hosts when allow_local_remote_servers is enabled, so
-# that flag (set above) is what makes this entry effective.
-nextcloud_extra_hosts:
-  - "auth.gymb.souveredu.ch:172.16.19.101"
-
 # LDAP backend (Authentik LDAP outpost)
 nextcloud_ldap_enabled: true
 nextcloud_ldap_config:
@@ -118,13 +109,12 @@ nextcloud_oidc_providers:
     display_name: "Login with Authentik"
     client_id: nextcloud
     client_secret: "{{ _authentik.nextcloud_oidc_secret }}"
-    # Discovery via the internal FQDN (LAN-only) — the DMZ has no
-    # hairpin-NAT for the public IP, so server-to-server calls to
-    # auth.gymb.* would time out. The traefik router for auth.int.*
-    # rewrites the Host header to auth.gymb.souveredu.ch before the
-    # request reaches authentik, so the iss claim authentik emits still
-    # matches the public hostname the browser sees during login.
-    discovery_url: "https://auth.int.gymb.souveredu.ch/application/o/nextcloud/.well-known/openid-configuration"
+    # Discovery via the public FQDN. It resolves (internal DNS view) to
+    # the DMZ reverseproxy, which the backend subnet can now reach, so
+    # the server-to-server call stays in the LAN while the iss claim and
+    # all listed endpoints match the public hostname the browser sees
+    # during login — no host-rewrite or /etc/hosts pin needed.
+    discovery_url: "https://auth.gymb.souveredu.ch/application/o/nextcloud/.well-known/openid-configuration"
     scope: "openid email profile"
     unique_uid: true
     mapping: