D-057 -- review items for END OF DEPLOYMENT (do not action mid-deploy)

These are real findings surfaced while building the D-057 provider-vip split. None block the deploy; each is deferred to a post-D-011 reconciliation sweep so we don't re-architect inside a step. Logged here so they are not lost.

R1. provider-vip-maas-standup.md CREATE blocks are now redundant with the script. scripts/provider-vip-standup.sh is the tested execution path for creating the plane. The runbook's Phase-2 create blocks duplicate that logic (two sources of truth -- this is how the MTU-source bug nearly drifted between them). KEEP the runbook for its still-unique parts: Phase-1 audit, the virbr1 vlan_filtering gate, and the deferred jumphost-gateway reads. RECONCILE: trim the create blocks to a pointer at the script, or annotate them "superseded -- see script". (User: noted for end-of-deployment review, not trimmed now.)

R2. scripts/review-bundle.py is STALE (pre-D-052) and is NOT a current gate. Run against today's committed bundle it reports ~30 FAILs: its PHANTOM_BINDING_KEYS check forbids exactly the per-endpoint bindings (shared-db/amqp/certificates/cluster/ ha/internal) that D-052 deliberately added, and its VIP check expects DUAL VIPs at octets .224-235 in the old 10.12.8 "metal" net -- the bundle has TRIPLE VIPs at .50-.60 across provider-public/metal-admin/metal-internal. So review-bundle.py predates D-052 entirely and does not describe the live bundle.

- The "verify_bundle.py / 8/8 harness" referenced in the redeploy notes is NOT at
  this repo HEAD (d575a25) -- only review-bundle.py is.
- INTERIM GATE for the D-057 change: scripts/d057-bundle-check.py (focused, fail-
  closed, proven FAIL-on-pre / PASS-on-post). It checks only the D-057 invariants.
- RECONCILE: either bring review-bundle.py forward to D-052/053/D-057 (rewrite
  PHANTOM check, VIP check to triple + provider-vip 10.12.24, octets 50-60), or
  restore/commit the newer verify_bundle.py and retire review-bundle.py.

R3. Committed bundle uses machines 8/9/10/11; the live cloud ran 0/1/2/3. Repo-fidelity gap (the committed bundle is not the as-deployed bundle). Does NOT affect D-057 (the carve is hostname-based; the MAC trim is by MAC). RECONCILE the bundle machine block + to: placements to whatever the redeploy actually uses.

R4. oob CIDR -- RESOLVED by D-058. oob adopts 10.12.60.0/22 (the design-docs value). The live virsh power gateway 10.12.64.1 -> 10.12.60.1 (scripts/lib-hosts.sh VIRSH_POWER_ADDRESS) is part of the D-058 foundation cascade -- see D-058-renumber.md.

R5. gateway_ip default-route watch-item (post-deploy, not end-of-deploy). provider-vip subnet carries gateway_ip=10.12.8.1 (post-D-058). This mirrors provider-public's existing .4.1 (which already coexists with metal-admin .8.1 without hijacking the node default), so risk is low -- but VERIFY after redeploy that every API unit's default route is still via metal-admin 10.12.12.1, not .8.1: juju exec --all -- ip route show default If any unit defaults via .8.1: blank the subnet gateway_ip (set PVIP_GATEWAY="" in scripts/provider-vip-standup.sh and re-apply) or pin the node default-gateway subnet to metal-admin. provider-vip reachability does not depend on its own gateway in v1.

R6. ovn-chassis-octavia has no bridge-interface-mappings (expected -- it is the octavia-side chassis). Left unchanged. Noted only so it is not mistaken for an omission during review.