feat(cloudflared): manage tunnel ingress locally via ConfigMap

The tunnel was remotely managed from the Zero Trust dashboard: the
Deployment ran 'run --token' and ignored the ConfigMap that already
existed in the tree. Switch to a locally-managed tunnel so the ingress
routing table lives in git.

- deployment: mount cloudflared-config (config.yml) and the
  cloudflared-credentials Secret; drop TUNNEL_TOKEN env
- configmap.yaml: per-hostname ingress rules to ingress-nginx via the
  CoreDNS rewrite, plus a 404 catch-all
- secret-generator: register the SOPS-encrypted credentials file
- homelab-ca: add the cloudflared namespace copy so the connector trusts
  the ingress certificate (force-ssl-redirect makes plaintext impossible)

Credentials were extracted from the live cloudflared-token Secret and
re-encrypted with SOPS; no plaintext secret is committed.

k8s/apps/cloudflared/configmap.yaml

@@ -0,0 +1,58 @@
+# cloudflared ingress configuration.
+#
+# This list is the tunnel's routing table: for each incoming hostname the
+# connector dials the matching origin. The final rule is a catch-all, so a
+# hostname absent from this list gets 404 from the connector — DNS alone does
+# not route a request into a service.
+#
+# Management model: this file makes the tunnel LOCALLY managed. cloudflared is
+# given a credentials file instead of a token, so Cloudflare stops pushing the
+# remotely-managed ingess list and this ConfigMap wins. Revert the Deployment to
+# `run --token` to return to the dashboard-managed list.
+#
+# Origin services self-reference the public hostname. That resolves because
+# CoreDNS rewrites each of these names to ingress-nginx
+# (terraform/files/coredns/Corefile), so the connector reaches the in-cluster
+# ingress instead of looping back out through Cloudflare.
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: cloudflared-config
+  namespace: cloudflared
+data:
+  config.yml: |
+    tunnel: 32d0bf93-e1bd-45b8-93a9-71ff9f83de80
+    credentials-file: /etc/cloudflared/creds/credentials.json
+
+    # WARP-to-Tunnel routing. The remotely-managed config had this enabled;
+    # dropping the key would break WARP access to private addresses. cloudflared
+    # 2026.x has no `enabled` field — the key's presence is what enables it, and
+    # `enabled: true` here makes the binary warn about an unused key.
+    warp-routing: {}
+
+    ingress:
+      - hostname: paperless.riotpiao.com
+        service: https://paperless.riotpiao.com
+      - hostname: authentik.riotpiao.com
+        service: https://authentik.riotpiao.com
+      - hostname: img.riotpiao.com
+        service: https://img.riotpiao.com
+      - hostname: riotpiao.com
+        service: https://riotpiao.com
+      - hostname: grafana.riotpiao.com
+        service: https://grafana.riotpiao.com
+      - hostname: gotify.riotpiao.com
+        service: https://gotify.riotpiao.com
+      - hostname: igotify.riotpiao.com
+        service: https://igotify.riotpiao.com
+      - hostname: poimen.riotpiao.com
+        service: https://poimen.riotpiao.com
+      - hostname: comfyui.riotpiao.com
+        service: https://comfyui.riotpiao.com
+      - hostname: forgejo.riotpiao.com
+        service: https://forgejo.riotpiao.com
+      # ZITADEL. Without this rule the connector answers 404 for the hostname
+      # even though the DNS CNAME points at the tunnel.
+      - hostname: zitadel.riotpiao.com
+        service: https://zitadel.riotpiao.com
+      - service: http_status:404