memory: waterland-studio upstream fixes landed, container stays pinned

waterland-dev merged PR #5 (main now 464dfc2), fixing both landmines at
source: the gpu extra declares cupy-cuda12x[ctk], and the renderer spawns
sys.executable -m waterland.cli instead of re-entering uv mid-job.

The running container deliberately stays on 8025366. Its own [ctk] install
and UV_NO_SYNC/UV_OFFLINE pins already neutralise both defects, so a rebuild
would buy reliability that is already present — and the project is in
wind-down. Both guards are kept rather than dropped: the header requirement
is a property of this slim image, not of the upstream extra, and the uv pins
are now cheap defence-in-depth against any future path that re-enters uv.

Also records waterland-dev's confirmation of the unbounded job-store growth
and the operator's green-light on their startup-rehydrate fix. That PR
merging is the rebuild trigger: one update.sh run lands the rehydrate and
464dfc2 together. Marks the inbox drained.

persistent-memory.d/2026-08-19-waterland-studio-containerised.md

@@ -6,9 +6,17 @@ a FastAPI + SPA GPU service fronting the `waterland` CLI, running as a bare
 `stacks/waterland-studio/`, `restart: unless-stopped`, healthy on
 irv-ml1:8410. Commits `a2b5b58`, `8189076`.
 
-Tracking `main` per operator: PR #4 merged and `main` HEAD is exactly the
+Tracking `main` per operator: PR #4 merged and `main` HEAD was exactly the
 pinned `8025366`, so tracking-a-moving-ref and keeping-the-pin agreed anyway.
 
+**`main` has since moved to `464dfc2` (PR #5, 2026-08-19) — the running
+container is deliberately still on `8025366`.** #5 fixes landmines 1 and 2 at
+the source (see below). Nothing on the service is broken by staying behind:
+the image's own `[ctk]` install and env pins already neutralise both, so a
+rebuild buys reliability that is already present, and the operator has called
+wind-down on the project. `update.sh` picks up `main` on the next rebuild that
+has a real reason behind it.
+
 ## Build context lives OUTSIDE the compose dir — on purpose
 
 `/opt/waterland-studio/src` is the checkout; the Dockerfile is passed
@@ -31,6 +39,14 @@ built venv. Pinned with `UV_NO_SYNC=1`; `UV_OFFLINE=1` alongside so that if the
 pin ever stops holding the job fails **loudly** instead of quietly rebuilding a
 slower environment.
 
+**Fixed upstream in `464dfc2`:** the server now spawns
+`sys.executable -m waterland.cli` directly — no resolver in the render path at
+all. **The pins stay anyway.** They cost nothing and are now defence-in-depth:
+if any future code path re-enters `uv` inside the container, the job fails
+loudly instead of quietly dropping to the numpy backend. `uv` itself must stay
+in the image regardless — it performs the build-time `uv sync` /
+`uv pip install`, and this is a single-stage build.
+
 ## Landmine 2 — cupy needs CUDA HEADERS, which the host never had to declare
 
 Every render died 1.7s in with:
@@ -53,7 +69,12 @@ hundred MB against ~6 GB for a `-devel` base image. It runs **after**
 `uv sync`, because sync prunes what it does not know about.
 
 Reported upstream: it is an undeclared runtime dependency of the `gpu` extra,
-and anyone running this without a system toolkit hits it.
+and anyone running this without a system toolkit hits it. **Declared upstream
+in `464dfc2`** (`gpu` is now `cupy-cuda12x[ctk]>=13`). **The explicit install
+stays in the Dockerfile**: the header requirement is a property of *this*
+image — a slim base with no system CUDA toolkit — so it belongs in the file
+that creates the problem, not inherited from an extra two repos away. It also
+survives any future restructuring of the `gpu` extra.
 
 ## Landmine 3 — the GPU index inside the container is not the host's
 
@@ -96,6 +117,19 @@ startup**. Consequences:
 Reported to waterland-dev with evidence; **not patched from the infra side** —
 it is their code. Prune the volume by hand if it bites first.
 
+**waterland-dev confirmed it (2026-08-19)** — their "bounded ~500 MB" handover
+claim holds within one process lifetime and nowhere else, which on a
+`restart: unless-stopped` service is the wrong lifetime to have bounded. They
+have **surfaced a startup-rehydrate fix to the operator** rather than opening a
+third PR during wind-down. **Operator green-lit it (2026-08-19)** — a PR is
+expected. Volume at **61 MB / 16 job dirs** as of 2026-08-19 08:30Z —
+unchanged since first observed, so there is no clock on it.
+
+**This is the rebuild trigger.** When the rehydrate PR merges, one `update.sh`
+run on irv-ml1 moves the container off `8025366` and picks up `464dfc2`'s
+fixes in the same motion — the "rebuild with a real reason behind it" named
+above. Nothing else on the infra side needs coordinating.
+
 ## Access
 
 Repo is not anonymously readable (a bare clone 403s). Operator granted