Railway template doesn't validate/generate DATABASE_ENCRYPTION_KEY in correct format, causing cryptic failure only surfaced when password-protecting a video

[nicolasiscoding]

Description
Deploying Cap via the official Railway one-click template can leave DATABASE_ENCRYPTION_KEY set to an invalid length/format with no validation or clear error at deploy time or server startup. The failure only surfaces later, when a user tries to password-protect a video, producing a cryptic server error:

Error verifying video password: Error: Encryption failed: Invalid encryption key format: Encryption key must be 32 bytes (64 hex characters)

This is the same underlying issue as #1357, which was closed after the reporter regenerated their key with openssl rand -hex 32. That fixed their case, but the root gap remains: nothing catches or explains an invalid key until a user happens to exercise the one feature (video passwords) that touches it.

Suggested improvements

1. Validate DATABASE_ENCRYPTION_KEY format at server startup and fail fast with a clear error, rather than only failing when a specific feature is used.
2. 2. If the Railway template auto-generates this variable, confirm the generator produces a 64-character hex string (32 bytes) — a mismatched generator (e.g., a generic 32-character secret generator) would explain why this keeps recurring.
3. 3. Surface the exact fix command (openssl rand -hex 32) directly in the Railway template's deploy-time variable description, not just in the general self-hosting docs.
      Environment
      Deployment: Self-hosted via Railway one-click template (ghcr.io/capsoftware/cap-web:latest)

Related issues
Related to #1357

[linear]

CAP-782