Set Secure session cookies correctly behind TLS-terminating proxies

Problem

Session cookie creation and all deletion paths set Secure from r.TLS != nil (internal/server/ui_auth_pages.go:121-145, :149-168). In the documented production model, the public origin is HTTPS (DEPLOYMENT.md:59-65) but TLS may terminate at Dokploy/reverse-proxy infrastructure, leaving the upstream Go request with r.TLS == nil.

TRACK_SLASH_PUBLIC_ORIGIN is already validated as an HTTPS production origin, but it is not used for cookie policy.

Impact

Production can emit an otherwise valid session cookie without the Secure attribute. The browser may then send the bearer token over an HTTP request before redirect/HSTS handling, exposing an indefinitely reusable session (until the separate session-expiry ticket is fixed) to network interception.

Acceptance criteria

• Derive production cookie security from trusted configuration such as the validated public origin, or an explicit secure-cookie setting.
• Do not trust arbitrary X-Forwarded-Proto input unless trusted proxies are explicitly configured.
• Keep localhost HTTP development supported without weakening deployed HTTPS cookies.
• Apply one shared policy to set, clear, and stale-cookie cleanup paths.
• Consider migrating to a __Host- cookie name (Secure, Path=/, no Domain) without leaving stale legacy cookies.
• Add tests for direct TLS, TLS-terminated proxy, localhost HTTP, and cookie clearing.