Record the SPA fallback fix and the morning FTP re-test finding

The SPA fallback (2c44888/b0b58d2) is deployed to VPS as b0b58d2,
verified via curl and headless-browser on real routes, a missing
asset, and /api, both locally and through the public domain.

Also updated the FTP saga: re-testing this morning found a Rocky-only
failure with the VPS confirmed off, which the two-machine-collision
theory from last night can't explain. Decided to stop self-testing
and wait for a real answer from LVGMC about the account's connection
policy rather than keep guessing through trial and error.

docs/UPDATE_ROADMAP.md

@@ -7,7 +7,7 @@ This document tracks proposed WeatherTool improvements. Work should be delivered
 - **Windows source workspace:** source editing, review, and Git operations only; do not install dependencies, compile, build, run, or test here.
 - **Rocky development and staging:** the sole compile, build, development-runtime, and test environment, with production-like Docker staging at `http://192.168.1.101:9190`.
 - **Git over SSH:** Windows pushes reviewed commits to a private bare repository on Rocky; the Rocky staging checkout pulls those commits and rebuilds.
-- **Ubuntu VPS deployment:** release `3eddf95` is publicly operational behind Cloudflare strict TLS, Nginx, and Authelia, ingesting real LVĢMC open-data station/water-temperature observations on a schedule; the `weather` table was wiped and re-populated fresh once the UTC/local timezone mismatch between sources was fixed. FTP (`ENABLE_LVGMC_FTP_JOBS`) was briefly enabled 2026-08-23 but reverted to `false` the same night after the `ltv` account failed to authenticate from the VPS specifically (crash-looped the app in-process until caught and reverted) — real credentials work fine from Rocky, not yet from the VPS; see the changelog for full diagnosis. The VPS does not compile or build the project.
+- **Ubuntu VPS deployment:** release `b0b58d2` is publicly operational behind Cloudflare strict TLS, Nginx, and Authelia, ingesting real LVĢMC open-data station/water-temperature observations on a schedule; the `weather` table was wiped and re-populated fresh once the UTC/local timezone mismatch between sources was fixed. FTP (`ENABLE_LVGMC_FTP_JOBS`) stays `false` on both Rocky and the VPS pending a real answer from the LVGMC contact about the `ltv` account's connection/rate policy — see Phase 7 for the full, still-unresolved diagnosis. The VPS does not compile or build the project.
 - **Workplace production:** remains separate until changes are reviewed, tested, and explicitly approved for workplace use.
 
 Do not synchronize `.env`, database directories, generated dependencies, build output, or provider credentials between machines.
@@ -272,13 +272,24 @@ running in parallel until each real source is proven, not cut over in one step.
          IP isn't on that list even though Rocky's apparently is. The VPS's
          outbound IP is `57.128.250.38`, in case it needs to be given to the
          LVGMC contact for allowlisting.
-      **Next step (morning, user): double-check the password in
-      `/srv/weathertool/.env.staging` on the VPS character-for-character
-      against the decoded value; if it's correct, ask the LVGMC contact
-      whether the `ltv` account is IP-restricted and whether the VPS's
-      outbound IP needs adding.** FTP stays on for Rocky (working there);
-      VPS runs open-data only until this is resolved and re-verified the
-      same careful way — watch-and-confirm, not assume-and-move-on.
+      **2026-08-24 morning update: the two-machine-collision theory above
+      does not fully hold.** Independently confirmed the `ltv` account
+      itself isn't hard-locked (a FileZilla login from a separate PC on the
+      same network succeeded, browsed `/ltv/tabulas`, saw
+      `Latvija_faktiskais_laiks.csv` freshly modified — LVGMC's feed is
+      alive). A manual isolated fetch from Rocky then succeeded too. But
+      re-enabling Rocky's *scheduler* (`ENABLE_LVGMC_FTP_JOBS=true`, VPS
+      confirmed still `false` the whole time) failed on its very next
+      scheduled attempt, ~4 minutes after the successful manual test, on
+      Rocky alone with nothing else touching the account. Three attempts in
+      ~10 minutes, two succeeded and one didn't, with no pattern found yet
+      (not simultaneity, not which machine, not obviously attempt spacing).
+      Reverted `ENABLE_LVGMC_FTP_JOBS` to `false` on Rocky again immediately.
+      **Decision: stop self-testing this via trial and error — every
+      attempt might be feeding an unknown rate/session limit — and wait for
+      the user to ask the LVGMC contact directly what the account's
+      connection policy actually is.** Both Rocky and the VPS run open-data
+      only until there's a real answer.
 - [x] Researched DMI HARMONIE credentials while waiting on the above and
       confirmed live (not just from search results, which claimed a specific
       date that wasn't independently verified): DMI's Forecast Data EDR and
@@ -369,9 +380,8 @@ Status: in progress
 - Both the VPS and Rocky `weather` tables now hold only real open-data station observations; their original synthetic rows were backed up and wiped 2026-08-23.
 - LVGMC forecast CSV fixtures are not yet available.
 - HARMONIE GRIB fixtures are not yet available.
-- The private LVGMC FTP feed has real credentials as of 2026-08-23 and is enabled on Rocky (`ENABLE_LVGMC_FTP_JOBS=true`); the DMI HARMONIE forecast feed remains gated (`ENABLE_HARMONIE_JOBS`, default off) pending real credentials.
+- The private LVGMC FTP feed has real credentials as of 2026-08-23, but `ENABLE_LVGMC_FTP_JOBS` stays `false` on both Rocky and the VPS pending a real answer from LVGMC about the `ltv` account's connection/rate policy (see Phase 7). The DMI HARMONIE forecast feed remains gated (`ENABLE_HARMONIE_JOBS`, default off) pending real credentials — turned out not to need any (DMI dropped its key requirement), but wiring it up is deferred to a dedicated verification session (see Phase 7).
 - Existing automated test coverage is minimal.
-- Direct refreshes on newer frontend routes can return 404 until the backend gains a general SPA fallback.
 - Full Docker build context scanning on Rocky can fail on the container-owned `postgres/` bind directory; do not loosen its permissions.
 
 ## Change log
@@ -431,3 +441,4 @@ Record completed work here by date and commit after the Git workflow is establis
 | 2026-08-23 | `3315f00` | Fix the same UTC-vs-local mismatch in Ūdens's `observedAt` display (`WaterTemperatureService`) — same open-data portal, same root cause, display-only (internal recency filtering was already self-consistent either way) | Yes — Scala tests; verified live via `/api/water-temperatures`: `observedAt` now matches real local time |
 | 2026-08-23 | `3eddf95` | Split `ENABLE_LEGACY_PROVIDER_JOBS` into independent `ENABLE_LVGMC_FTP_JOBS`/`ENABLE_HARMONIE_JOBS` — real LVGMC FTP credentials arrived today, real DMI HARMONIE credentials haven't, and the combined flag would have enabled both together, crash-looping the app on HARMONIE's still-placeholder values via `parMapN` | Yes — Scala tests; caught before it could happen (the Grib job was ~15 min from its first scheduled run when noticed) and reverted within under a minute; re-verified after the fix that only "Fetch Weather Stations" scheduled, not "Fetch Grib" |
 | 2026-08-23 | `dc04f66` | Fix `deploy/vps/compose.yml` hardcoding `LVGMC_USER`/`PASSWORD`/`URL` to inert placeholder strings directly in the file (unlike `POSTGRES_*`, which already read from `.env.staging`) — real credentials added to `.env.staging` alone would have had no effect until this switched to the same `${VAR}` substitution pattern. Enabled `ENABLE_LVGMC_FTP_JOBS` on the VPS | Yes — `docker compose config` syntax valid; VPS `app` container came up healthy with real credentials loaded (would have crashed immediately on missing-config if not) |
+| 2026-08-24 | `2c44888`–`b0b58d2` | Replace the hardcoded per-route static-file list (`/station`, `/cities`, `/latvia`, `/database`, `/harmonie`, `/lvgmc-forecast`, `/bridinajumi`) with a general SPA fallback: real files serve as-is, anything else falls back to `index.html` so the SolidJS router handles it client-side — fixes a real, user-reported bug where a direct hit (e.g. a browser refresh) on `/faktiska` or `/udens-temperatura` 404ed instead of loading the app, since those two routes were never added to the old list. A missing file under `/assets` specifically still 404s properly rather than silently serving HTML, so a stale tab after a future deploy gets a clean error instead of a confusing JS parse failure | Yes — first attempt silently no-op'd because the fix was built into a `git archive HEAD` image before being committed (classic mistake, caught immediately by re-testing and finding identical old behavior); after committing, verified via curl on all previously-working routes, both previously-broken routes, a missing asset (404), a real asset (200), and `/api` (200), then a full headless-browser render check (zero console errors, real data, correct nav state) on a genuine direct hit — not just HTTP status codes; deployed to VPS in release `b0b58d2`, verified the same way through both the loopback port and the public domain (Authelia gate still correctly redirects unauthenticated requests) |