immich: bulk-import Anca's Elements photo archive into her account

Grows pve/nfs-data 3T → 4T (online lvextend + resize2fs) to absorb ~340 GB
of new originals landing under /srv/nfs/immich/upload during the import.

Adds:
- module "nfs_anca_elements_host" — RO PVC over /srv/nfs/anca-elements,
  consumed only by the import Job (not mounted in immich-server).
- kubernetes_job_v1.anca_elements_import — immich-go v0.31.0 uploader
  posting to immich-server.immich.svc:2283 with Anca's API key (synced
  via the existing immich-secrets ExternalSecret from
  secret/immich.anca_api_key). Filters to image extensions, bans the
  non-photo top-level dirs (filme/, Music/, carti/, courses, installers,
  docs, etc.), puts every asset in the album "Poze (Elements)". Default
  `--pause-immich-jobs` is disabled — non-admin keys can't pause jobs.
- docs/architecture/storage.md — note the new 4 TB size in 3 places.
- docs/runbooks/grow-pve-nfs-lv.md — captures the one-shot lvextend
  procedure (no pve-host TF stack exists for this).

Job is removed in the follow-up cleanup commit once the upload completes;
the PVC stays for a videos batch later.

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

docs/runbooks/grow-pve-nfs-lv.md

@@ -0,0 +1,47 @@
+# Runbook: Grow `/srv/nfs` LV (`pve/nfs-data`)
+
+Use when `/srv/nfs` on the PVE host is filling up and the workloads writing to it cannot be slimmed down. The LV sits on the LVM-thin pool `pve/data` (10.54 TB total). Thin-pool free space is the real gate — confirm before extending.
+
+## When to use
+
+- `df -h /srv/nfs` shows usage > ~85 % and projected growth exceeds free space within a backup retention window.
+- An upcoming bulk write (media import, restore) needs headroom that the current free space won't absorb.
+
+## Steps
+
+1. **Check thin-pool headroom on PVE host:**
+
+   ```bash
+   ssh root@192.168.1.127 'lvs pve/data; lvs pve/nfs-data; df -h /srv/nfs'
+   ```
+
+   The `pve/data` thin pool's `Data%` should leave room for the extension (target `Data%` after extend < 90 %).
+
+2. **Extend the LV and online-resize ext4:**
+
+   ```bash
+   ssh root@192.168.1.127 '
+     lvextend -L +1T pve/nfs-data &&
+     resize2fs /dev/pve/nfs-data
+   '
+   ```
+
+   Both commands are safe online: `lvextend` only grows allocation, `resize2fs` extends ext4 while mounted.
+
+3. **Verify:**
+
+   ```bash
+   ssh root@192.168.1.127 'lvs pve/nfs-data; df -h /srv/nfs'
+   ```
+
+   `df` should show the new size; `Use%` should drop proportionally.
+
+## Notes
+
+- **Not Terraform-managed.** PVE host LVs live outside the IaC tree (no `infra/stacks/pve-host/`). Record the new size in `docs/architecture/storage.md` (the "HDD NFS" line and the diagram label) in the same commit.
+- **Thin-pool overcommit warning** from `lvextend` is informational — it reports the sum of all thin volume virtual sizes (currently ~12 TiB) vs. the physical pool (10.7 TiB). Real fill is `pve/data` `Data%`; ignore the overcommit warning unless `Data%` itself is climbing toward 100 %.
+- **`/srv/nfs-ssd`** lives on a separate LV (`ssd/nfs-ssd-data`) backed by SSDs — the same `lvextend`/`resize2fs` pattern applies, but the source pool is `ssd/data`.
+
+## Backout
+
+Online shrinks are unsafe with active workloads. Don't try to shrink `pve/nfs-data` in place — restore from snapshot or migrate data out and rebuild the LV instead.