Reverse-proxy deployment: explicit forwarded-header setting for the dashboard and TLS-shape docs

[coopernetes]

Summary

fogwall can be deployed behind an ingress or load balancer that terminates TLS, with plaintext inside the cluster. The git and proposals listeners need nothing for that shape: the git protocol does not consult forwarded headers, and fogwall reads none and emits none on those paths. The dashboard does depend on them, and today that dependency is implicit and unconditional.

Current state

• The dashboard resolves forwarded scheme, host and port on every request so that OIDC login redirects, other absolute URLs, and the session cookie's Secure flag reflect the external address. This is always on and cannot be turned off, and it accepts the headers from any client that can reach the dashboard port directly.
• server.service-url already provides the external base for the setup guide and SCM OAuth linking; the setup guide falls back to deriving it from the request when unset and says so.
• The forwarded-header no-op on the proxy servlet is recorded as TODO comments rather than a decision.

Wanted

• Forwarded-header handling on the dashboard becomes an explicit setting. Its documentation states the precondition: when on, the dashboard listener must be reachable only through the ingress that sets the headers. The default is chosen with existing ingress deployments in mind, since turning it off on upgrade would break their login redirects and cookie security; a startup log line names the active setting and the precondition.
• Admin guide coverage of the two supported shapes: TLS at fogwall, and TLS at the ingress with plaintext inside the cluster, including that server.service-url should be set in the second.
• The proxy servlet's TODO comments are replaced by a stated posture: fogwall sends no forwarded headers upstream. Cache eviction and dead-reference cleanup #589 carries the comment change.

Boundaries

• Packaging is Helm chart follow-ups: ingress for TLS termination, PVC, RBAC, OpenShift guidance #597: the Helm ingress template sets server.service-url and the setting above.
• Git and proposals listeners do not process forwarded headers; nothing on those paths reads a client address today. If a client address is ever recorded for audit (Log every administrative action with actor, target and outcome #585, feat: audit log and compliance reporting #99), that is where the trust question for those listeners arises, and it is decided then.
• The chunked-request behaviour through intermediaries documented in the admin guide is a separate concern and stays there.