Correct two doc sections written before the real CI bugs were found

The changelog claimed ci.yml #1 verified green (it didn't -- that was a
wrong WebFetch summary of the Gitea Actions page, reported as fact without
checking it visually) and CONTINUOUS_INTEGRATION.md described the
HOME/cache permission warning as harmless (it wasn't -- it blocked
resolving actions/checkout entirely). Both corrected with what actually
happened: three real, different bugs, found only by running the workflow
and reading user-provided screenshots of the actual failures.

docs/CONTINUOUS_INTEGRATION.md

@@ -93,12 +93,16 @@ workflow section for why.
 work. The runner is available only while the coding PC, Docker, and these
 containers are running.
 
-One known, non-fatal warning in the runner logs: `cannot init cache server,
-it will be disabled: mkdir /.cache: permission denied` — the runner
-container runs as uid 1000 with no writable `$HOME`, so the `actions/cache`
-action type is unavailable. Nothing in the current workflow uses it. Fixable
-later by setting `HOME=/data` in the runner's environment if caching
-becomes worth adding.
+`compose.yml` sets `HOME: /data` on the runner container. Without it, the
+first real run failed every job, both times it was tried, with `Unable to
+clone https://github.com/actions/checkout ...: mkdir /.cache: permission
+denied` — this was initially misdiagnosed (both in the runner's own startup
+log, which only calls it "cache server disabled", and in this doc's first
+draft) as merely disabling the optional `actions/cache` action type. It
+actually blocks resolving *any* remote action at all: with uid 1000 and no
+writable `$HOME`, the runner has nowhere to git-clone an action's source
+into before running it, and `actions/checkout` is exactly that. `HOME=/data`
+(the already-writable bind-mounted data directory) fixed it.
 
 ## WeatherTool workflow
 
@@ -120,7 +124,9 @@ proven for this project rather than bootstrapping a second language runtime
 into a single shared container:
 
 - **`backend`** (`hseeberger/scala-sbt:17.0.2_1.6.2_2.13.8`, the same image
-  used all session for local Rocky builds): checkout, `sbt -batch test`.
+  used all session for local Rocky builds): installs a real Node 20 via
+  NodeSource's setup script (see below for why), checkout, `sbt -batch
+  test`.
 - **`frontend`** (`node:20-bookworm`): checkout, `npm ci`, `npm run
   typecheck`, `npm run build`, `npm audit`, `npm audit --omit=dev` — the
   same five checks already documented as the manual Rocky verification
@@ -134,8 +140,24 @@ plugin logs a graceful warning and continues; nothing in the current test
 suite (`FileNameServiceSpec`; `ParserSpec` has no live assertions) touches
 `sys.env` or a live database.
 
-The first complete green run was verified on 2026-08-24 for commit
-`5b88e69` (`ci.yml #1`, 33s).
+`actions/checkout` is a JavaScript action — it needs a Node runtime inside
+the job container to execute at all, which `hseeberger/scala-sbt` doesn't
+have. `frontend`'s image already has one, so it passed as soon as the
+`HOME` fix landed. `backend` needed an explicit install step first
+(`apt-get install nodejs` alone wasn't enough either: `hseeberger/scala-sbt`
+is Debian **bullseye**-based, whose default apt `nodejs` package is a stale
+Node 12, too old to parse `actions/checkout@v4`'s modern JS —
+`SyntaxError: Unexpected token '{'` on a class static block. NodeSource's
+`setup_20.x` script installs an actual current Node 20 regardless of the
+distro's packaged version).
+
+None of the three bugs above were caught by writing the workflow carefully
+or by the pre-write `sbt test` dry run — all three only surfaced by actually
+running it and reading the real failure in the Gitea Actions UI, once per
+bug, in order: the `HOME`/cache fix, then the missing-Node fix, then the
+wrong-Node-version fix. The first four runs (`ci.yml #1`–`#4`) all failed.
+The first complete green run was `ci.yml #5`, commit `2c78ae8`, 2m24s,
+verified 2026-08-24.
 
 ## Current boundary