Phase 1: encryption hardening (logging, transport, secrets, storage)

From the PR description

Summary

Phase 1 of the encryption review - hardening that ships before the envelope-encryption work in Phase 2.

• Logging: strip PII from request/error logs; no key prefixes or auth headers.
• Transport: helmet + HSTS on the backend; apiBase env gate so the frontend can't fall back to a hardcoded host.
• Secrets: new DOWNLOAD_SIGNING_SECRET (Secrets Manager: mike/download-signing-secret) decoupled from SUPABASE_SECRET_KEY, so future Supabase key rotations don't invalidate chat-rendered download links.
• Storage: SSE on every PutObject (falls back to SSE-S3 today; KMS lands in Phase 2).
• API surface: /system/llm-providers returns booleans only - no key-prefix leak.
• Test scaffold + ESLint guard (Phase 0, prerequisite).
• Dead code: drop frontend/src/lib/supabase-server.ts (unreferenced service-role helper) - let us strip SUPABASE_SECRET_KEY from the Amplify env.

Infra changes already made (out-of-band, in prod)

• New Secrets Manager entry mike/download-signing-secret (32-byte hex).
• New ECS task def mike-backend:6, service rolled to :6 (adds DOWNLOAD_SIGNING_SECRET to secrets[]).
• Rotated SUPABASE_SECRET_KEY to the new sb_secret_* format.
• Removed SUPABASE_SECRET_KEY from prod Amplify app env.

Deferred to follow-ups

• Download-token TTL + userId binding - chat-rendered links live in chat_messages.content forever; needs a refactor of chatTools.ts link-rendering to a fetch-on-demand stub first.
• 36 pre-existing ESLint errors / 68 warnings - separate branch.

Test plan

• Staging-validated end-to-end against a live Supabase project + MinIO (throwaway harness in scripts/staging/).
• Both pre-merge checks passed: NEXT_PUBLIC_API_BASE_URL set on prod Amplify; SUPABASE_SECRET_KEY wired in prod ECS task def.
• After merge: confirm Amplify build succeeds and ECS rolls forward with no health-check flaps.