docs: correct two stale claims in CLAUDE.md that misdirect live work

Both found while writing felhom.eu runbooks/target-selection.md.

1. The demo host block said the t740 is the designated drill+build VM host "but no
   drill VM is provisioned there yet". Stale since 2026-07-25 -- VM 300 (drill-r50)
   has been there since. The sentence read as discouragement from the very box the
   operator ruling designates, which is part of why a drill went to DooPlex instead.
   Now says the ruling is realized and to start there, points at the new
   target-selection runbook, and notes drill.qcow2 on DooPlex is a BAKE fixture, not
   a drill target. Agent version dropped (it changes several times a day; the hub
   host list and --version are the authorities) and the t740's PVE node name added.

2. RETRACTED the block's claim that the agent "does not run at all" at the remote
   site because localapi binds the LAN literal 192.168.0.162 and the service has
   "never started" -- with an outstanding config edit needing Viktor GO. That was
   true before R-50 and is false now: since the island migration (2026-07-25)
   localapi binds 169.254.253.1:8443 on vmbr9, which is location-independent by
   design, and proxmox.endpoint is https://127.0.0.1:8006. Verified live 2026-07-30:
   service active, version 0.115.0, and GET /disks answered over the island -- the
   whole R-116 payload capture went through it. A session trusting the old text
   would not have attempted the read that worked. The recorded remote-site address
   was also wrong (.162, not .147), so it now says re-check instead of asserting one.

No code, no version bump, so no CHANGELOG entry (that file is version-keyed) and
REPORT.md is left holding the v0.115.0 record rather than being overwritten by a
docs fix.

CLAUDE.md

@@ -88,11 +88,14 @@ internal/storage/    storage observer + durable ids + role/claim classifiers + S
 ## Demo host (for live tests)
 
 Node **`demo-felhom`**, API `https://192.168.0.162:8006`. SSH alias `felhom-pve` (root@pam) —
-available to CC as plain `ssh felhom-pve`. A **second demo node `demo-hp`** (HP t740, agent 0.93.0,
-`ssh demo-hp` — no baked key; break-glass root via hub `host_recovery/demo-hp-bb76ea` + `sshpass`) is
-the **designated drill+build VM host** per the 2026-07-25 operator ruling — **but no drill VM is
-provisioned there yet** (the drill `drill.qcow2` still lives on DooPlex, powered off). Both nodes +
-the break-glass recipe: `felhom.eu/documentation/operations/nodes.md`. The agent pins the served leaf cert — verify the
+available to CC as plain `ssh felhom-pve`. A **second demo node `demo-hp`** (HP t740, node name
+`felhom-host`, `ssh demo-hp` — no baked key; break-glass root via hub `host_recovery/demo-hp-bb76ea` +
+`sshpass`) is the **designated drill+build VM host** per the 2026-07-25 operator ruling, and that ruling
+is **realized** — it hosts drill VM `300` (`drill-r50`), so **start there**, not on DooPlex. (The
+historical golden-bake `drill.qcow2` still lives on DooPlex and is a bake fixture, not a drill target.)
+**Which box is safe to break, and what may be done to each:
+`felhom.eu/documentation/runbooks/target-selection.md`** — read it before any destructive test. Both
+nodes + the break-glass recipe: `felhom.eu/documentation/operations/nodes.md`. The agent pins the served leaf cert — verify the
 fingerprint still matches before a live run. Selftest modes (run locally on DooPlex, pointed at the
 demo API): `--selftest[=read|task|hub|storage|backup|restore-test|pbs-verify]`; no flag = the daemon.
 
@@ -101,13 +104,17 @@ demo API): `--selftest[=read|task|hub|storage|backup|restore-test|pbs-verify]`;
 > felhom-pve = 100.70.170.35; the `Host felhom-pve` entry in `~/.ssh/config` on DooPlex already
 > points there (the direct-LAN path stays available as `Host felhom-pve-lan`). Delete this block on
 > return. All documented `ssh felhom-pve` / `pct exec` workflows are unchanged. Path is **direct**
-> (not DERP), ~37 ms rtt per hop. At the remote site the host is on **DHCP** and currently holds
-> `192.168.0.147` — so the PVE API is at `https://192.168.0.147:8006` there, and **the agent does
-> not run at all**: `localapi` binds the literal `192.168.0.162` → `bind: cannot assign requested
-> address` → the service is `failed` and has never started at the remote site. Fixing it means
-> editing `listen_addr` in `/etc/felhom-agent/agent.json` **and** the guest's bootstrap endpoint
-> (plus the leaf-cert SAN the controller pins) — Viktor GO required. Details + findings:
+> (not DERP), ~37 ms rtt per hop. At the remote site the host is on **DHCP**; re-check its address
+> rather than trusting one written here (`ip -br addr show vmbr0` — it read `192.168.0.162/24` on
+> 2026-07-30, and `felhom-pve-lan` from DooPlex is still `No route to host`). Details + findings:
 > `felhom.eu/documentation/audits/AUDIT-vacation-remote-ops-2026-07-20.md`
+>
+> **The "agent does not run at the remote site" warning this block used to carry is RETRACTED
+> (2026-07-30) — it was true before R-50 and is false now.** `localapi` no longer binds a LAN literal:
+> since the R-50 island migration (2026-07-25) it binds `169.254.253.1:8443` on `vmbr9`, which is
+> location-independent by design, and `proxmox.endpoint` is `https://127.0.0.1:8006`. Verified live:
+> `systemctl is-active felhom-agent` → `active`, `felhom-agent --version` → 0.115.0, and the per-guest
+> local API answered `GET /disks` over the island. No config edit and no Viktor GO are outstanding.
 
 > **Legacy: Windows workstation.** Until 2026-07-19 CC ran on Windows 11; `pct` commands over SSH
 > needed `export MSYS_NO_PATHCONV=1`, and every remote command used