Legacy deployment fix (Postgres password support)

[roon9e]

Legacy setup uses TELESRV_POSTGRES_DSN=postgres://telesrv:telesrv@127.0.0.1:5432/telesrv_main?sslmode=disable which could not be changed to safe random password because it was hardcoded in docker-compose.yml

[iamxvbaba]

Thanks for the contribution. I reviewed commit 5638b9b49788dca9d62e7768ad9b64b2a4191b24 against the current target branch. The verdict is BLOCK because the legacy Compose path is not currently deployable with the submitted configuration.

1. The documented/default Compose startup is now broken by the Redis password requirement.

   deploy/docker-compose.yml makes TELESRV_REDIS_PASSWORD mandatory, but .env.example still defines it as an empty value. The repository's documented docker compose -f deploy/docker-compose.yml up -d flow does not instruct the user to create and populate these new required values.

   I reproduced the following configuration matrix:

   • Baseline Compose without an environment file: passes validation.
   • PR Compose without an environment file: fails during interpolation.
   • PR Compose with the repository's .env.example: still fails because TELESRV_REDIS_PASSWORD is empty.
   • PR Compose with both passwords explicitly set: passes validation.

   Please either preserve a working development default, or update the template, startup documentation, and server-side Redis password configuration together so the documented path works as submitted.

2. The new PostgreSQL password variable is not a complete credential contract.

   The database container now reads TELESRV_POSTGRES_PASSWORD, while the server still connects through the independently configured TELESRV_POSTGRES_DSN, whose example retains the old telesrv password. On a fresh volume, changing only the newly introduced password variable initializes PostgreSQL with the new password but leaves the application trying the old DSN. On an existing PostgreSQL volume, changing POSTGRES_PASSWORD/TELESRV_POSTGRES_PASSWORD does not rotate the existing role password at all; I verified that the role password hash remained unchanged after recreating the container with the new value.

   Please establish one authoritative credential source for both PostgreSQL initialization and the application DSN, account for URL encoding in the DSN, and provide an explicit password-rotation/upgrade procedure for existing volumes.

Additional notes:

• The exact PR head currently has a red Go CI check due to TestGetFileSingleflightSharesImmutableRangeBacking. That failure is unrelated to these Compose changes and is already fixed on the current target branch, but CI must be rerun on the repaired head.
• Please add a legacy Compose validation test covering no .env, the checked-in example, custom passwords, and an existing-volume upgrade.

For verification, I applied the exact two-file contribution to the current private target: go test ./... -count=1 and go vet ./... passed, as did the public diff/privacy/dependency checks. The Compose configuration matrix and PostgreSQL 17 existing-volume probe reproduced the two blockers above.