docker: logs follow a held connection, and networks can be removed

Two gaps the Docker tab had against Dockhand and against its own Services
tab next door.

Logs: one `docker logs -f` per viewer over a WebSocket, the shape the
Services tab's journal tail already uses, instead of asking again every two
seconds. stdout and stderr both, with stderr marked so the page can colour
what went wrong. Docker replays the backlog down two pipes in no particular
order, so the opening 300 ms is held and sorted by the stamp Docker wrote;
after that the log is live and in order. A reconnect resumes from the last
line rather than from the top — `--since` is inclusive and two lines can
share a nanosecond, so the client drops what it has already shown by line,
not by "later than". A container that has stopped ends the stream at once,
so reconnects back off to 15 s.

Networks: remove and prune, which images and volumes have had all along.
The overview now says which containers are attached to each network, so the
✕ appears only on one nothing uses, and never on bridge, host or none.
`network rm` prints the real reason and then an aggregate "exit status 1",
so the message shown is the first line, not the last.

Prune is not exercised against `core`: several networks here belong to
stacks that are merely down, and pruning would give them new subnets on
their next deploy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

PLAN.md

@@ -595,11 +595,25 @@ something long in one, switch away and back, refresh — it's all still there.
       pulls it. Its `git_repositories` and `git_stacks` tables are **empty**, so nothing
       here uses it — dropping it is the honest answer unless Mitchell says otherwise.
     - *Webhooks, OIDC, LDAP, vulnerability scans.* All four tables empty. Nothing to move.
-  - **Known gaps in the tab itself**, worth closing whether or not Dockhand goes:
-    - *Removing networks* — volumes and images can be pruned and removed, networks cannot.
-    - *Logs are polled with `--since` rather than followed over a held connection.* That was
-      deliberate and works, but a long tail is choppier than the Services tab's live tail,
-      which does hold a connection. Worth reconciling the two.
+
+  **Done 2026-09-25 — the two gaps in the tab itself.**
+  - *Logs are followed over a held connection*, the way the Services tab follows a journal
+    (`internal/api/docker_logs.go`, `/api/docker/containers/{id}/logs/tail`): one
+    `docker logs -f` per viewer, stdout and stderr both, stderr coloured as an error. A
+    reconnect resumes from the last line's timestamp, so a container that restarts or a
+    phone that slept doesn't replay what is already on screen; the client dedupes by line
+    rather than by "later than", because `--since` is inclusive and two lines can share a
+    timestamp. Docker replays the opening backlog down two pipes in no particular order, so
+    the first 300 ms is held and sorted before it is sent. The polled `?since=` endpoint
+    stays — it is what the resume is built on. Reconnects back off to 15 s, since a
+    container that has stopped ends the stream immediately.
+  - *Networks can be removed and pruned* — `POST /api/docker/networks/{remove,prune}`, the
+    shape images and volumes already had. The overview says who is attached to each one, so
+    the ✕ is only offered on a network nothing uses and never on Docker's own three. Prune
+    is deliberately untested against this host: `core` has several networks belonging to
+    stacks that are merely down (`pihole_default`, `transmission_default`, `gluetun_default`
+    among them), and pruning would take them and hand them new subnets on the next deploy.
+
   - **The `*:2375` question, which this is the moment to settle.** A stack deployed to
     `grid` or the Mac still goes over `tcp://<node>:2375` from the hub. Decide whether the
     hub should instead ask the node's own Ham Lab to deploy locally, which would end the