Revert VPS FTP after it crash-looped the app; document the diagnosis

The ltv account fails to authenticate from the VPS specifically
(works fine from Rocky with the same credentials, network path to
ftp.meteo.lv:21 confirmed fine from the VPS too) — narrowed to either
a password transcription error in .env.staging or LVGMC IP-allowlisting
the account, neither confirmable without inspecting the password.
Caught via the overnight watch this was set up for rather than
assumed safe; reverted ENABLE_LVGMC_FTP_JOBS to false on the VPS
immediately once the failure was confirmed real, restoring stable
operation. FTP stays enabled on Rocky, where it works.

deploy/vps/compose.yml

@@ -32,10 +32,15 @@ services:
       POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
       POSTGRES_HOST: postgres
       ENABLE_SCHEDULED_JOBS: "true"
-      ENABLE_LVGMC_FTP_JOBS: "true"
+      # Briefly "true" on 2026-08-23, reverted same night: the ltv account
+      # fails to authenticate from the VPS specifically (works fine from
+      # Rocky), which crash-looped the whole app in-process via parMapN
+      # before this was caught and reverted. Leave false until the VPS-side
+      # auth failure is diagnosed and re-verified — see docs/UPDATE_ROADMAP.md.
+      ENABLE_LVGMC_FTP_JOBS: "false"
       ENABLE_HARMONIE_JOBS: "false"
       DEBUG: "false"
-      # LVGMC_* now read real values from .env.staging (real FTP credentials
+      # LVGMC_* read real values from .env.staging (real FTP credentials
       # obtained 2026-08-23). HARMONIE stays on inert placeholders until real
       # DMI credentials exist — the provider service is still constructed at
       # startup even with its scheduled job off, so it needs some value.