Support an isolated beta/staging environment

## Goal

Add a beta/staging environment where changes can be tested without disrupting active production races.

## Current constraints

The production host currently has:

- 1 vCPU
- 1.9 GiB RAM with no swap
- About 738 MiB available RAM during normal operation
- About 505 MiB used by the existing Docker containers
- About 14 GiB free disk space after routine cleanup

Normal beta traffic would be negligible. The main constraints are the fixed memory cost of duplicated services and contention from building images on the single CPU. A fully duplicated stack would add roughly 500 MiB at idle, leaving too little safety margin on the current host.

## Recommended direction

Prefer a fully isolated beta stack on a separate small VPS. This keeps beta deployments, migrations, restarts, memory spikes, and broken builds from affecting production. An on-demand VPS that is stopped when unused could keep the cost low.

If beta must share the production host, first resize it to at least 4 GiB RAM, add service resource limits, and build images in CI rather than on the server.

## Likely implementation work

- Add beta.letscube.net, TLS, and a separately registered WCA OAuth callback.
- Parameterize the Compose project name and currently single-environment deployment script.
- Use separate secrets, sessions, Mongo database, PostgreSQL database, Redis namespace or instance, and migration target.
- Configure beta API, Socket.IO, CORS, and client build origins.
- Separate deployment locks, logs, image and rollback tags, health checks, and backups.
- Prefer CI-built images that each environment pulls and deploys.
- Document beta deployment, rollback, reset, and data-seeding procedures.

## Rough effort

- Minimal usable environment: 1–2 focused days.
- Polished setup with CI image builds, verified rollback, documentation, and end-to-end testing: 2–4 days.

## Alternative options

- Run beta API/socket processes against logically isolated databases on the current host: lower memory use, but it shares production failure modes.
- Run a fully isolated beta stack on demand on the current host: workable only with careful resource management and still risks production contention.
- Host only a beta client against production: very low effort, but it does not safely test backend, protocol, migration, or deployment changes.