Lock stacks during compose runs, cache stats, persist runtime state (0.47.0)

F7 — Nothing stopped two compose operations landing on the same stack. There
was a busy flag, but is_busy() was only ever read to colour the status column;
no lifecycle handler consulted it before acting. Two tabs, or auto-update
picking up a stack somebody had just clicked, both ran pull + up -d against the
same project and raced over recreating containers.

Lifecycle calls, the two deploy WebSockets and the auto-update pass now take a
real lock; a second caller gets 409 (or an error frame and close 4409) and
auto-update skips and retries next cycle. The lock is a row rather than a set
in one worker's memory, so it holds across workers and across a restart, and it
carries an expiry — a worker killed mid-deploy would otherwise strand the stack
with no fix short of editing the database.

F10 — /api/stacks/stats sampled every running container on every call, one
blocking daemon request each, and both the dashboard and the stacks list poll
it every five seconds. Two tabs on a 40-container host meant a sustained ~16
samples a second. Cached for 4s behind a lock so concurrent callers share one
sweep, the same shape dashboard_service already used for its fleet aggregate.

F11 — Three module dicts assumed exactly one uvicorn worker without saying so
and were lost on restart. The busy set is the lock above. The image update
cache is now mirrored to SQLite, so a restart shows the badges immediately
instead of blanking them for up to an hour, and the already-notified marks come
back with them rather than re-announcing the same updates. The login rate
limiter is a table, so it cannot be cleared by getting the process to restart
and no longer multiplies by the worker count.

The constraint that shaped this: compose_service and update_service are shared
with the agent, which has no database. Neither may import one. So the lock is a
separate service the central app enforces at its own entry points, and update
persistence is an opt-in callback the central app registers in its lifespan —
the agent registers nothing and behaves exactly as before. A test asserts
update_service never imports the database, since that is the kind of thing a
later change breaks silently.

Both new nets were checked by reverting the fix: dropping the lock from
_lifecycle fails six tests, removing the stats cache fails the one that names
the behaviour.

Also wires up cache pruning in the same sweep — without it both the dict and
the table grew one entry per image tag ever run, for the life of the install.

31 new tests (729 total).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Dk43rmEeRfYi5wsLDbmfyG

README.md

@@ -15,6 +15,24 @@ as intuitive as Dockge, as capable as Portainer for Compose workflows.
 > (Auto-update) + Phase 23 (Secrets & configs) + Phase 24 (Design System v2)
 > complete.
 
+## Upgrading to 0.47.0 — nothing to do
+
+Three pieces of state moved out of process memory and into the database, and
+the live-stats endpoint got a cache. No configuration changes, no migration
+steps; the new tables are created on first start.
+
+- **Stacks can only run one compose operation at a time.** A second `start` /
+  `update` / `down` on a busy stack answers `409` instead of racing the first
+  one over the same containers. Auto-update skips a stack you are already
+  deploying and picks it up next cycle.
+- **`GET /api/stacks/stats` is cached for four seconds.** It sampled every
+  running container on every call, and the dashboard and the stacks list both
+  poll it every five seconds — two open tabs on a 40-container host meant a
+  sustained ~16 daemon calls a second.
+- **The update cache and the login rate limiter persist.** Both used to reset on
+  restart; the rate limiter also used to multiply by the worker count, so
+  neither behaved as documented with `--workers` set.
+
 ## Upgrading to 0.46.0 — everyone is signed out once
 
 Sessions now hold their access token in memory and the refresh token in an
@@ -86,6 +104,10 @@ it is what your saved destination credentials are encrypted with.
   stop / restart / pull / update` via `docker compose`.
 - **Live status** — running / partial / stopped / error / updating, computed from
   Docker container labels.
+- **One operation per stack** — a lifecycle call takes a lock (a row, so it
+  holds across workers and across a restart) and a second one gets `409` while
+  it is held; auto-update skips a stack somebody is already deploying. Locks
+  carry an expiry, so a worker killed mid-deploy does not strand a stack.
 - **Real-time logs** — streamed over WebSocket, color-coded per service.
 - **Live deploy console** — deploying from the editor streams `compose up`
   output (image pulls, container creation) over a WebSocket in real time instead
@@ -133,6 +155,9 @@ it is what your saved destination credentials are encrypted with.
 - **Image update checker**: background task compares the local manifest digest with
   the registry (Docker Hub / ghcr / lscr / private v2 with token auth); update
   badges on the Images page + an "updates available" banner on the dashboard.
+  Results are cached in the database, so a restart shows the badges immediately
+  instead of blanking them until the next sweep — and does not re-announce
+  updates it already notified about.
 - **Port conflict detector**: pre-deploy check against host-bound ports
   (`/proc/net/tcp[6]`) and running container bindings, with a confirm dialog.
 - **Resource limits**: CPU/memory sliders in the editor → `deploy.resources.limits`.
@@ -538,7 +563,7 @@ Same three commands the CI runs — `build-and-push` only starts once they pass.
 ```bash
 cd backend
 pip install -r requirements-dev.txt
-pytest                            # 698 tests, no Docker daemon needed
+pytest                            # 729 tests, no Docker daemon needed
 ruff check .
 cd ../frontend && npx tsc --noEmit -p tsconfig.json
 ```
@@ -564,6 +589,14 @@ HTTP. `tests/test_schema_migration.py` builds a database with the *old* user
 table and asserts the added column is backfilled rather than left NULL, which is
 what would otherwise have signed out every user on every install.
 
+`tests/test_stack_locking.py` and `tests/test_runtime_state.py` cover the state
+that moved into the database: that a busy stack answers 409 without ever
+reaching Docker, that an expired lock is taken over rather than stranding the
+stack, that the stats cache serves repeat callers from one sweep, and that the
+update cache and rate limiter survive a restart. One of them asserts that
+`update_service` never imports the database — it is shared with the agent,
+which has none, so persistence has to stay opt-in.
+
 `tests/test_bundled_templates.py` covers the 83 shipped templates: each must
 parse, name an image per service, keep `.env.example` in sync with the variables
 compose actually reads, ship every file it bind-mounts, and never come with a