Assess Murmur production readiness and deployment path

Assess the current Murmur application and existing Ansible/Scaleway deployment path, identify release blockers and operational risks, and define a staged route to the first production workload. Current context: - Murmur itself is not deployed. - The application repository has local Compose packaging but no CI/CD. - The Ansible repository already contains a dedicated host inventory entry and a digest-pinned Compose deployment role. - Existing control-plane and worker images are publicly retrievable from Scaleway Container Registry. Verified inventory and findings: - No Murmur control-plane or worker Instances currently exist in the configured Scaleway project; the Ansible inventory target is unreachable and its IP is not owned by that project. - The existing Ansible role deploys one control-plane container plus local PostgreSQL and publishes unauthenticated HTTP transport on public port 8080; no TLS, backup, restore, CI/CD, or application metrics are defined. - Worker ingress is correctly default-deny and permits port 8080 only from the intended control-plane IP. The control-plane security group and Ansible firewall currently permit SSH and/or API ingress publicly. - Immutable registry digests exist for the current authenticated control plane and an 8.51 GiB amd64 worker image. The registry namespace is public and releases were built manually. - L4-1-24G capacity is currently scarce in fr-par-2 and in shortage in fr-par-1; only fr-par-2 has a worker security group, while the application config has only one security-group ID for all zones. - Rust format/check/tests, worker type/lint/tests (using `python -m pytest`), Compose rendering, and targeted Ansible syntax/lint validation pass. The documented direct pytest invocation does not resolve the local package. - Startup recovery can requeue running work while the old GPU process continues, allowing duplicate/concurrent GPU work after a crash; provisioning workers can also be orphaned because provider resources are not reconciled by tag. - The database stores source URLs and transcripts indefinitely, has no deletion/retention policy, and client retries are not idempotent. Authentication direction selected: - Replace the static control-plane bearer secret with OAuth 2.0 client credentials from a dedicated Kaukus production ZITADEL service account. The Murmur project and JWT-enabled Kaukus service account have been created in the default ZITADEL organization, and client credentials have been generated. - Configure JWT access tokens and validate them locally in Murmur against the exact issuer, RS256/JWKS key, expiry/not-before, Murmur project audience, and an allowlisted Kaukus service-account subject. Do not rely on audience alone. - Prefer local JWT verification over per-request introspection so ZITADEL outages do not break status polling and Murmur needs no introspection client secret. Keep HTTPS and source-network restrictions as separate controls. - Keep the independently network-restricted ephemeral-worker token out of this OAuth change. - The planned Rust ZITADEL replacement currently advertises and implements only authorization-code grants. Adopting this direction makes compatible client-credentials JWT issuance and machine-secret authentication an explicit identity-cutover dependency. Acceptance criteria: - Current deployment assets and external resources are inventoried. - Production blockers are prioritized with evidence from code and infrastructure. - The target security/network, persistence/backup, observability, and image-release model is decided. - A staged rehearsal, deployment, smoke-test, rollback, and first-workload plan is ready for implementation. Final outcome: - Murmur and its PostgreSQL/Caddy control plane are deployed and healthy on the replacement host with digest-pinned images, HTTPS, JWT authentication and source-IP restriction. - Kaukus completed the one-way Swiftner replacement migration and authenticated production connectivity is verified. - L4-only demand-driven provisioning is enabled with zero warm workers and a one-worker cap; prior bounded Norwegian, Danish, multi-chunk and silence-regression workloads passed. - Remaining hardening work is separated into worker transport encryption, observability, orphan reconciliation and credential rotation.