ci: harden release promotion flow

[gabedalmolin]

Summary

Harden the release and deployment flow so production is promoted intentionally from published releases, while manual dispatch is reserved for controlled non-production deploys.

What changed

• refactored the deploy workflow into explicit resolve deployment context, verify promotion candidate, deploy, and validate deployment phases
• added exact-ref verification before every deployment with dependency install, Prisma generation, lint, typecheck, build, coverage, Prisma migrate deploy, and integration tests
• blocked manual production deployments and moved workflow_dispatch toward staging or homolog-style environments
• made deployment concurrency environment-aware instead of using a single shared production bucket
• enforced mandatory production smoke prerequisites so production fails clearly when RAILWAY_PUBLIC_URL is missing or invalid
• updated the README and Railway deployment guide to document the promotion model, environment-scoped secrets, and expected GitHub Environment protections

Validation

• npm run lint
• npm run typecheck
• npm run build
• npm test
• workflow YAML parsed successfully with the local yaml package

Risks/Notes

• production deploys are now intentionally slower because the release ref is re-verified before promotion
• manual production dispatch is blocked by design; production promotion must go through a published GitHub release
• the workflow now assumes Railway credentials are configured on the selected GitHub Environment, not only as repository-wide secrets
• GitHub Environment protection rules still need to be configured manually in the repository settings