[Bug] Make the Crove Post Beta runtime deployment durable

[JOY]

Incident

beta-post.crove.com timed out because the Beta runtime stack was absent from crove-prod:

• postiz-beta, postiz-postgres-beta, and postiz-redis-beta did not exist.
• Port 127.0.0.1:5001 refused connections.
• No Beta volumes existed.
• Production postiz remained healthy and was not restarted.

Temporary runtime recovery

The isolated Beta stack was restored under /opt/crove-beta using ghcr.io/dos/crove-post:beta, separate PostgreSQL and Redis containers, separate volumes, and port 127.0.0.1:5001.

Live verification:

• https://beta-post.crove.com/api/public/v1/integrations now returns 401 without credentials instead of timing out.
• DOSClaw Beta can resolve the OAuth credential and call Crove Post. list_destinations now returns No publishing destinations were found, which is the expected result for an account without connected social channels.

Source drift to fix

scripts/docker-compose.beta.yaml still:

• Uses ghcr.io/gitroomhq/postiz-app:latest instead of ghcr.io/dos/crove-post:beta.
• References external networks crove_postiz-network and crove_temporal-network, while the VM currently exposes postiz-docker-compose_postiz-network and temporal-network.
• Has no deployment automation that installs or reconciles the Beta stack on crove-prod.

Acceptance criteria

• Update the canonical Beta compose file to the Crove fork image and the actual VM network contract.
• Add an application health check that validates the backend API, not only container state.
• Add an idempotent deployment or reconciliation path for the Beta stack.
• Confirm production containers are never recreated by the Beta deployment.
• Verify local port 5001, public Beta endpoint, OAuth, and DOSClaw list_destinations after deployment.