Automate Kamal deployments with Gitea Actions

Investigate and design a deployment mechanism that runs the existing Kamal deployment through the self-hosted Gitea Actions runner instead of requiring a developer workstation. Constraints: - Keep Kamal as the deployment orchestrator. - Reuse existing repository configuration and scripts rather than creating parallel deployment paths. - Separate staging and production controls, secrets, concurrency, and rollback concerns explicitly. - Do not enable production deployment until the workflow and operational safeguards are validated. Acceptance criteria: - Current Kamal and CI/deployment setup is audited. - A concrete trigger, environment, secret, runner, concurrency, and approval design is agreed. - Required repository changes and external Gitea/runner configuration are identified. - The proposed validation and rollout path includes a safe staging rehearsal and production rollback. Current design and status: - Gitea 1.27.3-cloud ignores deployment environments, so repository access and protected release branches provide the authorization boundary; all repository writers are trusted with deployment capability. - Main production is the only destination in scope; the unused Poland destination is excluded. - Initial rollout uses manual workflow dispatch with preflight, deploy, and rollback operations. Automatic deployment remains disabled until the team chooses master or a newly initialized production branch. - Repository changes implement serialized Kamal operations, pinned SSH host keys, isolated temporary credentials, input/ref validation, health verification, failure diagnostics, and an operations runbook. - Static workflow, shell, policy, cleanup, and live host-key validations pass. - External rollout is blocked on provisioning a repository-scoped kaukus-deploy runner and adding dedicated 1Password and SSH Actions secrets; no existing runner is available on the current host.