Trust the ingress forwarded headers, and make every cookie Secure #608

Part of #607.

Why

The pods sit behind a TLS-terminating ingress. The app must know the scheme of the original request
(X-Forwarded-Proto), so that it builds https:// URLs and sets cookie flags from the real scheme.
CoreWebExtensions.AddCpdCoreWeb clears KnownProxies but keeps the default KnownNetworks
(loopback only), so the app does not trust the forwarded headers from the ingress. The comment on
AddAntiforgery records the same limit.

Scope

• Make UseForwardedHeaders trust the ingress. Either clear KnownNetworks as well (the pods are
  reachable only through the ingress), or set ASPNETCORE_FORWARDEDHEADERS_ENABLED=true. Record the
  trust decision in a comment.
• Confirm with DfE Sign-in that the https:// callback and sign-out callback URLs are registered for
  each environment, before deploying.
• Then set Cookie.SecurePolicy = Always outside Development for the antiforgery cookie, and remove
  the comment that explains why it is not set.
• Check the auth cookie gets the Secure flag.

Done when

• On a review app, the redirect to DfE Sign-in has an https:// redirect_uri.
• On a review app, every cookie the service sets (auth, session, antiforgery, correlation) has the
  Secure flag.
• Request.IsHttps is true in a deployed pod, and the app sends its own HSTS header.
• Sign-in, sign-out and a POST after the sign-in expired still work on the review app.
• A unit test pins the forwarded-headers options.