Add blankpad-host auto-learn skills and memory store

Tracked the harness artifacts accumulated on blankpad (blank@), matching
the existing convention for the --home-dank-* memory stores and the 36
already-tracked managed-skills.

managed-skills (9): authentik-proxy-provider-app-link,
dankclaw-guard-chain-layer-diagnosis, e2e-arr-rawip-reachability-triage,
halogen-kv-pool-fit, lan-client-split-dns-fix, noctalia-reference,
rootless-quadlet-log-retrieval, ssh-key-bootstrap-no-sshpass,
swapfile-resize-safe-ordering.

memories (2 stores): --home-blank-.omp-- (dotfiles_git, handy_lifecycle,
input_permissions) and --home-blank-Projects-serverAppConfig--
(frank_large_quadlet).

Secret sweep before staging: no PEM blocks, no credential literals.
Content is fleet topology/IPs only, same class as the tracked dank stores.

agent/managed-skills/rootless-quadlet-log-retrieval/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: rootless-quadlet-log-retrieval
+description: "Retrieve logs for a rootless Podman Quadlet service on the Dank fleet — which command covers which time window, and the sudo/per-user-storage trap"
+---
+
+# Rootless Quadlet Log Retrieval (Dank fleet)
+
+Applies to any service deployed as a **rootless** Quadlet `.container` unit (frank-large on Dankclaw is the reference case). Rootless storage is per-user, so the deploy user matters more than the container name.
+
+## Step 0 — establish ownership before choosing a command
+
+```bash
+# Which manager owns the unit, and which user runs it?
+systemctl --user status <name>.service      # works => rootless user unit
+loginctl show-user <user> -p Linger         # Linger=yes => starts at boot
+```
+
+If `systemctl --user` knows the unit, **every** subsequent command runs as that user with NO `sudo`.
+
+## Step 1 — pick the log source by time window
+
+| Need | Command |
+|---|---|
+| Current instance, tail | `podman logs --tail 200 <name>` |
+| Current instance, follow | `podman logs -f <name>` |
+| Across restarts/recreates | `journalctl --user -u <name>.service -n 200 --no-pager` |
+| Time-bounded | `journalctl --user -u <name>.service --since "14:30"` |
+| Crash/restart signal only | `journalctl --user -u <name>.service -p warning` |
+| Kernel-side evidence (OOM, SVM) | `sudo journalctl -k --since ...` |
+
+Quadlet units commonly run `--replace --rm`. Consequence: **`podman logs` is destroyed when the container is recreated**; the journal captured `podman run`'s stdout and is the only durable record. When the question is "what happened before the last restart", go straight to `journalctl --user`.
+
+## Step 2 — the traps
+
+- `sudo podman logs <name>` → `Error: no such container`. Root's store does not contain rootless containers. Same for `sudo podman ps`.
+- A system-level `journalctl -u <name>` returns nothing for a user unit — the `-u` must be paired with `--user`.
+- During a first-start weight download, health checks report unhealthy **by design**. Do not read that as a crash; check whether the payload file is still growing.
+- Vendor verbose switches (e.g. `HALOGEN_VERBOSE=1`, `HALOGEN_DMALLOC_LOG=1`) are a **config change**: they go through git and `deploy.sh`, never a live env poke on the host.
+
+## Step 3 — if you cannot reach the host
+
+No SSH transport is configured on the `blank` dev box. Do not probe `dank@`/`frank@` and hope. Ask Frank for a key or alias, and label any answer derived only from repo files as **not live-verified**.