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

backend/routers/auth.py

@@ -1,14 +1,14 @@
 """Authentication routes + first-launch setup wizard."""
 from __future__ import annotations
 
-import time
-from collections import defaultdict, deque
+from datetime import datetime, timedelta, timezone
 
 from fastapi import APIRouter, Depends, HTTPException, Request, Response, status
-from sqlmodel import Session, select
+from sqlmodel import Session, delete, select
 
 import auth as auth_mod
 from database import get_session
+from models.runtime_state import LoginAttempt
 from models.user import (
     LoginRequest,
     RefreshRequest,
@@ -23,23 +23,38 @@ from services import audit_service
 
 router = APIRouter(prefix="/api/auth", tags=["auth"])
 
-# Simple in-memory rate limiter for login (max 10 / minute / IP).
-_LOGIN_HITS: dict[str, deque] = defaultdict(deque)
+# Login rate limit: max 10 attempts per minute per client IP.
+#
+# Kept in the database rather than a module dict. In memory it reset on every
+# restart — so an attacker could clear their own budget by getting the process
+# to restart — and with more than one uvicorn worker each worker enforced its
+# own limit, multiplying the real allowance by the worker count.
+#
+# The IP is only meaningful because uvicorn runs with --proxy-headers; without
+# that every request looks like it comes from the frontend container and this
+# would throttle all users together.
 _RATE_LIMIT = 10
-_RATE_WINDOW = 60.0
+_RATE_WINDOW = timedelta(seconds=60)
+#: Attempts older than this are deleted while we are in the table anyway.
+_RATE_RETENTION = timedelta(hours=1)
 
 
-def _check_rate_limit(ip: str) -> None:
-    now = time.monotonic()
-    hits = _LOGIN_HITS[ip]
-    while hits and now - hits[0] > _RATE_WINDOW:
-        hits.popleft()
-    if len(hits) >= _RATE_LIMIT:
+def _check_rate_limit(session: Session, ip: str) -> None:
+    now = datetime.now(timezone.utc)
+    session.exec(delete(LoginAttempt).where(LoginAttempt.at < now - _RATE_RETENTION))
+    recent = session.exec(
+        select(LoginAttempt).where(
+            LoginAttempt.ip == ip, LoginAttempt.at >= now - _RATE_WINDOW
+        )
+    ).all()
+    if len(recent) >= _RATE_LIMIT:
+        session.commit()
         raise HTTPException(
             status_code=status.HTTP_429_TOO_MANY_REQUESTS,
             detail="Too many login attempts, slow down.",
         )
-    hits.append(now)
+    session.add(LoginAttempt(ip=ip, at=now))
+    session.commit()
 
 
 #: The refresh cookie is scoped to the two endpoints that consume it, so it is
@@ -122,7 +137,7 @@ def login(
     session: Session = Depends(get_session),
 ) -> TokenPair:
     ip = request.client.host if request.client else "unknown"
-    _check_rate_limit(ip)
+    _check_rate_limit(session, ip)
     user = auth_mod.authenticate(session, body.username, body.password)
     if not user:
         raise HTTPException(