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/e2e-arr-rawip-reachability-triage/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: e2e-arr-rawip-reachability-triage
+description: "Triage an e2e admin-SSO failure on a *arr raw IP (192.168.0.112:8989) by probing from the box the browser runs on, instead of assuming the Mac is asleep and burning retries waking it."
+---
+
+# e2e raw-IP *arr failures — probe from the browser's box, not a peer
+
+`tests/e2e/specs/11-admin.spec.ts` navigates the real browser to
+`http://192.168.0.112:8989/` (Sonarr's forwarded IP on FrankBook-Pro). When it
+fails with `ERR_CONNECTION_TIMED_OUT` the instinct is "the Mac is asleep".
+Sometimes true. Not always — and waking it is not the only recovery.
+
+## The decisive question
+
+**Who cannot reach the port?** Playwright runs on the dev box (blankpad), not on
+a fleet host. A healthy probe from dankclaw proves nothing about the browser's
+path.
+
+```bash
+# 1. From the box that RUNS the browser:
+curl -s -o /dev/null -w '%{http_code}\n' --max-time 7 http://192.168.0.112:8989/
+
+# 2. From a LAN peer, same port:
+ssh dankclaw 'for p in 8989 7878 9696; do curl -s -o /dev/null -w "$p %{http_code}\n" \
+  --max-time 6 http://192.168.0.112:$p/; done'
+
+# 3. Liveness of the Mac itself (ICMP, not TCP):
+ping -c 2 -W 3 192.168.0.112
+```
+
+## Reading the matrix
+
+| peer probe | blankpad probe | ping | meaning |
+|---|---|---|---|
+| 200 | 200 | ok | transient — re-run the spec |
+| timeout | timeout | fails | Mac asleep; wake, ports return in seconds |
+| **200** | **rc=28** | **ok** | **path problem, not sleep** — ICMP allowed, TCP to those ports blocked. Waking and re-running cannot help |
+
+## If it is the third row, confirm the Mac is not at fault
+
+Through the dankclaw jump (`ssh dankclaw "ssh dank@192.168.0.112 ..."`):
+
+```bash
+pgrep -fl socat            # forwarders bound to 192.168.0.112:port
+netstat -an | grep -c 8989 # listening
+curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8989/   # 200 = app fine
+/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate
+```
+
+Forwarders up + loopback 200 + `Firewall is disabled` ⇒ the Mac is innocent. The
+block is between the dev box and the Mac, so stop optimising the Mac.
+
+## What to do instead
+
+Don't hold a deploy hostage to a known-environmental red gate:
+
+1. Verify the deployed service **directly** — its own ledger/health/real
+   completion — and state that the e2e gate was skipped or partially red, and
+   why (`deploy.sh --skip-e2e` prints exactly that warning, so the skip is
+   recorded, not hidden).
+2. Report the residual gap plainly: *"29/30 e2e pass; 11-admin fails on Sonarr's
+   raw IP from the dev box; peer probe returns 200, so the deploy is verified by
+   other means and the gate gap is a dev-box network path issue."*
+3. Do not weaken or skip the spec to make it green — it is guarding a real
+   SSO-plus-RBAC contract.
+
+## Note on the sleep case
+
+The classic flake is real: with the Mac asleep, ports refuse from **everywhere**
+including peers, ping latency runs ~150 ms, and an SSH/ping wake restores
+200/302 within seconds. That is the cheap first check — just don't stop there
+when the peer probe is already green.