Refine capacity numbers from LXC 104 summary; flag iGPU passthrough fix

- LXC 104 (docker) confirmed: 16 CPU, 31.25 GiB RAM (7.86 used / 25%),
  200 GiB boot disk at 47.7% — disk is the real near-term constraint,
  not RAM. Numbers propagated into Q11 (docs/11), docs/03 architecture
  table, and CLAUDE.md infra block.
- New optimization #26 in docs/12: fix the Intel Arc iGPU passthrough
  flagged as broken in the LXC notes. Concrete /etc/pve/lxc/104.conf
  snippet provided. Once working, TEI / infinity / Immich CLIP can run
  GPU-accelerated for ~5–10x throughput.
- New optimization #27: disk-pressure mitigation playbook (move Qdrant
  to unas if it grows, prune docker layers monthly, cap n8n executions).
- New optimization #28: shrink the LXC's 8 GiB swap to 2 GiB.

docs/12-optimization-opportunities.md

@@ -42,3 +42,27 @@ Observed from the node summary: 22 threads, 62 GiB RAM (32 GiB used, ~24 GiB of
 23. **NTP source via AdGuard.** AdGuard already resolves DNS for the LAN; pointing the host's `systemd-timesyncd` at `pool.ntp.org` resolved through AdGuard avoids any external dependency for time. One-line change in `/etc/systemd/timesyncd.conf`.
 24. **`fstrim.timer` enabled** for the SSD pool — verify with `systemctl status fstrim.timer`. Default-on in modern PVE, but quick to confirm.
 25. **Watchdog config** is irrelevant for a single-node setup (HA is the use case), so leave the default. Mentioned only so future agents don't add it speculatively.
+
+## Docker LXC (104) — observations & wins
+
+Confirmed allocation: 16 CPU, 31.25 GiB RAM (7.86 GiB used / 25%), 8 GiB swap (idle), **200 GiB boot disk at 47.7% used** — disk pressure outranks RAM pressure.
+
+26. **Fix the Intel iGPU passthrough.** The container's own notes flag the binding as "likely failing". Once `/dev/dri/{card0,renderD128}` is visible inside the LXC, both TEI and `infinity` can run embeddings on the Arc iGPU via OpenVINO / IPEX-LLM — typically **5–10× faster** than CPU. Equally, Immich's CLIP can be GPU-accelerated. The required config in `/etc/pve/lxc/104.conf`:
+    ```
+    lxc.cgroup2.devices.allow: c 226:0 rwm
+    lxc.cgroup2.devices.allow: c 226:128 rwm
+    lxc.cgroup2.devices.allow: c 29:0 rwm
+    lxc.mount.entry: /dev/dri/card0       dev/dri/card0       none bind,optional,create=file
+    lxc.mount.entry: /dev/dri/renderD128  dev/dri/renderD128  none bind,optional,create=file
+    lxc.idmap: u 0 100000 65536
+    lxc.idmap: g 0 100000 65536
+    lxc.idmap: g 44 44 1            # video group on host
+    lxc.idmap: g 104 104 1          # render group on host
+    ```
+    Then inside the container: `usermod -aG video,render <docker-user>` and run TEI with `--device cuda` replaced by the OpenVINO build (`text-embeddings-inference:cpu-1.5-openvino`). Not needed for Phase-3.1's volume but a clean upgrade path.
+27. **Disk is the bottleneck, not RAM.** 95 GiB used / 200 GiB on the boot disk. Each new container Phase-3 adds (TEI image ~500 MB, infinity ~600 MB, GraphDB image + repo data ~3 GB at startup, Qdrant data growth ~50 MB per 10 k embeddings) is small in isolation but adds up. Suggestions:
+    - Move **Qdrant data dir** (already inside `qdrant_scientific`) to a dedicated mountpoint on `unas` (storage pool) if it grows past ~10 GB. Until then, leave it.
+    - Configure **n8n executions retention**: `EXECUTIONS_DATA_PRUNE=true`, `EXECUTIONS_DATA_MAX_AGE=168` (7 days). Already in optimization #13.
+    - Schedule a **monthly `docker image prune --all --filter "until=720h"`** to recover layers from old image tags. Today's `40 containers` likely brings ≥30 dangling layers.
+    - Watch **Immich**'s `upload/` and `library/` — those are the realistic 50-GB-class consumers if photo sync ramps up.
+28. **The LXC has its own 8 GiB swap.** Combined with the host's 31 GiB, that's a lot of swap for guests that should never page. Drop the LXC swap allocation to 1–2 GiB (`pct set 104 -swap 2048`) — frees disk on the LVM-thin pool and forces issues to surface earlier rather than silently swap.