feat: in-app HTTPS/HSTS enforcement and secure-cookie defaults

[emmpaul]

Part of #417 (compliance-readiness epic).

needs-scoping. Transport security and encryption-at-rest are currently fully delegated to the operator. That is defensible for self-hosting, but it should be (a) documented and (b) made easy to get right with sensible in-app defaults.

Current state

• No URL::forceScheme('https'), no HSTS header, no forced-HTTPS middleware.
• config/session.php secure cookie = env('SESSION_SECURE_COOKIE'), unset by default.
• No field-level encryption (grep for encrypted casts / Crypt:: is empty); password is hashed only.
• Attachments on the private local disk, unencrypted; S3 available as a config flip with no SSE config.
• docker-compose.prod.yml explicitly makes TLS the operator's responsibility (reverse proxy).

Scope to decide, then implement

• Opt-in in-app HTTPS enforcement + HSTS header (env-gated, e.g. FORCE_HTTPS / trusted-proxy aware) so operators behind a terminating proxy get correct scheme + HSTS without hand-rolling it.
• Decide the default for SESSION_SECURE_COOKIE in production and document it.
• Decide whether to add optional S3 server-side encryption config and/or field-level encryption for any sensitive attributes (assess what, if anything, warrants it).
• Document the full encryption/transport posture and the operator's responsibilities (at-rest disk encryption, TLS, backups) on the Security & Compliance docs page and docs/self-hosting/.
• Any env changes documented in docs/reference/environment-variables.md; tests + 100% coverage for in-app behavior.

Scope the encryption-at-rest decisions before implementing — much of this may resolve to documentation + a couple of opt-in toggles rather than pervasive field encryption.