docs: clarify Serenity old-IP probe removal

docs/planning/SERENITY_CLEANUP_WAVE_1.md

@@ -64,8 +64,8 @@ From the live Serenity audit:
 - quick live checks did not surface immediate DB dependencies for `Wizarr`, `Shelfmark`, or `Notifiarr`
 - `Newt` is still needed
 - legacy Pi-hole containers are still running even though Technitium is now the intended DNS path
-- Serenity Newt-backed Pangolin routes still had stale health-check hostnames pointing at old `10.5.1.5` even though their target IPs had already been rewritten to `localhost`
-- live workaround applied on 2026-05-25: Serenity now carries runtime alias `10.5.1.5/32` on `br0` so those stale health checks resolve locally again
+- Serenity Newt-backed Pangolin routes still had stale health-check hostnames pointing at old `10.5.1.5` even though their target IPs had already been rewritten to `localhost`/`10.5.30.5`
+- a temporary `10.5.1.5/32` alias on `br0` validated the diagnosis, but it was removed because the old IP is no longer allowed on that VLAN; authoritative Pangolin health-check cleanup is still required
 
 ## Wave 1-A: legacy Pi-hole removal
 

docs/planning/SERENITY_DOCKER_AUDIT.md

@@ -210,9 +210,9 @@ Resolved on 2026-05-25:
 - Is `/mnt/user/appdate/reranker` intentional, or a typo that should be corrected before migration?
 - When Pangolin API write auth is available again, rewrite Serenity target health-check hostnames away from stale `10.5.1.5` so the runtime alias can be removed cleanly.
 
-## Pangolin / Newt live remediation applied
+## Pangolin / Newt live remediation status
 
-Live verification on 2026-05-25 showed Serenity Newt still probing stale pre-renumbering health-check URLs like `http://10.5.1.5:8787/` even though the Pangolin target objects already showed `ip=localhost` for those resources.
+Live verification on 2026-05-25 showed Serenity Newt still probing stale pre-renumbering health-check URLs like `http://10.5.1.5:8787/` even though the Pangolin target objects already showed `ip=localhost` or `10.5.30.5` for those resources.
 
 Affected target IDs observed live:
 - `15` (`autobrr`)
@@ -224,17 +224,24 @@ Affected target IDs observed live:
 - `58` (`romm`)
 - `69` (`gamevault`)
 
-Fast remediation applied live on Serenity:
-- `ip addr add 10.5.1.5/32 dev br0`
+Diagnostic probe performed live on Serenity:
+- temporarily added `10.5.1.5/32` to `br0`
+- this immediately restored health for several targets, proving the stale `hcHostname` diagnosis
 
-Post-fix verification:
-- Newt logs recorded recovery to healthy for targets `15`, `20`, `25`, `29`, `56`, and `57`
-- direct Serenity HTTP probes to `http://10.5.1.5:8785/` and `http://10.5.1.5:8457/` returned `200`
-- inside the `Newt` container, `wget` to `10.5.1.5:8785` and `10.5.1.5:8457` succeeded
+However, the old `10.5.1.5` address is no longer allowed on that VLAN, so the alias was removed again.
+
+Verification after removal:
+- `ip addr del 10.5.1.5/32 dev br0`
+- Newt immediately resumed failures such as:
+  - target `56` -> `http://10.5.1.5:8788/`
+  - target `57` -> `http://10.5.1.5:8990/`
+  - target `15` -> `http://10.5.1.5:7474/`
+  - target `25` -> `http://10.5.1.5:8787/`
 
 Interpretation:
-- the immediate production symptom was repaired without waiting for Pangolin API write access
-- this is only a runtime compatibility patch; it must be treated as temporary until the stale Pangolin `hcHostname` fields are authoritatively rewritten
+- the alias was useful as a proof-of-cause test only
+- it is not an acceptable steady-state fix here
+- the real remaining task is to authoritatively rewrite the stale Pangolin `hcHostname` values away from `10.5.1.5`
 
 ## Database dependency findings