Follow-up to #448: the hydramirror vhosts were pinned as static routes on the edge only because dynamic routes were always health-probed at / (Traefik marks non-2xx down) and mirror apps 404 there.
RESOLVED 2026-08-06: health_path now travels the full reporting chain.
- hydraskin v0.10.0: report user.hydra.health_path (label was already parsed, just dropped from the payload). Deployed on pi-node-003-nvme and pi-node-004-nvme via hydracluster exec.
- hydracluster v2.0.102: pass health_path through POST /api/v1/body/scales to /api/v1/nodes verbatim (length-capped like domain/endpoint). Deployed via hydracluster update --force on the server.
- hydrascalerouter v0.10.0: read health_path from cluster claims into registry.Claim. Deployed on the edge via install.
- Labels set: incus config set hydramirror user.hydra.health_path=/api/v1/health (pi-node-003), same for hydramirror-bxl1b (pi-node-004).
- Both static hydramirror routes removed from /root/.hydrascalerouter/config.yaml (backup config.yaml.bak-20260806-issue450). hydrabody.experiencenet.com remains the only static route - no scale claims it.
- Route cache /var/lib/hydrascalerouter/routes.json cleared once so provenance reads truthfully (sameRoutes ignores provenance, so the functionally-identical dynamic routes did not trigger a republish).
Verified: routes.json shows bxl1 -> pi-node-003-nvme/hydramirror and bxl1-b -> pi-node-004-nvme/hydramirror-bxl1b with health /api/v1/health; all vhosts 200 on their health endpoints. A future mesh renumbering now flows through the report chain with no static pin to go stale.
Runbooks updated: hydraskin.md and hydrascalerouter.md document user.hydra.health_path (required for any scale that does not serve 2xx on /).