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

Railway のワンクリックテンプレートとサーバーの起動設定から始め、DATABASE_ENCRYPTION_KEY がどのように生成、記述され、必要な 32 バイト形式に対して検証されるかを確認します。無効な値が明確なメッセージとともに早い段階で失敗し、テンプレートが指定された openssl コマンドを使った有効な 64 文字の 16 進数値を提供または記述していれば完了です。

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