Harden docker-compose to TLS-by-default (MinIO and other local services) #17

Context

While implementing #13 (MinIO document storage), the MinIO client was built with secure derived from minio_url's scheme (https:// vs http://), matching the existing "let the URL decide" pattern every other outbound client in this codebase already follows (see app.core.tls's comment on httpx clients).

Issue #13 originally called for the MinIO client to be hardcoded secure=True, on the reasoning that Phase 5 stood MinIO up with TLS deliberately ahead of any client, so the default/easiest path should be the compliant one. That reasoning is right for the Helm-deployed production MinIO, but docker-compose.yml's local MinIO (and every other local service — Postgres, Keycloak, llama-server, doc-search) still talks plaintext HTTP over the docker network. A hardcoded secure=True would break docker-compose up outright, which is out of scope for #13.

Scope

Move local dev (docker-compose.yml) to TLS-by-default across services that support it, most importantly MinIO, so:

• build_minio_client() (backend/app/storage/minio_client.py) can eventually drop its scheme-sniffing fallback and always expect secure=True in every environment, closing the gap between local dev and production behavior.
• Local dev exercises the same TLS code paths (CA bundle verification, cert mounting) that Helm/K3s deployments use, catching TLS-related bugs before they reach a real cluster.

Notes

• Needs dev-only certs generated/mounted for docker-compose (something like a local CA + service certs, analogous to what the Helm chart's cert-manager integration does for the cluster).
• Should cover MinIO first (most directly affected by Document storage: MinIO client, upload, extraction, retention #13); evaluate whether Postgres/Keycloak/llama-server local TLS is worth the added complexity or should stay plaintext-for-dev indefinitely.
• Related: docs/SECURITY.md's TLS decision log (Phase 5, Decision 2).