C1 follow-ups: verify the RDNSS we never set; correct a revert line that did not revert ...

Two defects in the C1 changelog, both found on review:

1. The RA advertises `RDNSS 2602:f3e2:f01:1` -- a field we never set; OPNsense
   auto-defaulted it to the edge's own LAN v6 address. Same failure class we avoided
   with mode=unmanaged (advertising a service that may not exist), one field over,
   and it slipped in BECAUSE the field was left unset. CHECKED: the edge's Unbound
   really does answer DNS on that v6 address (dig from voffice1 resolves; it works
   with no v6 egress because Unbound queries upstream over v4). Correct -- but by
   luck, not design. Set RDNSS explicitly when this RA config is reused on the
   DC0/DC1 edges at Stage 3.

   Bonus: this makes "services binding v6" EVIDENCE rather than inference -- a real
   v6-bound service answering real queries.

2. The address-revert line said `--commit 10.10.0.1 lan :: 64`, which does NOT clear
   the field -- it would SET the unspecified address. The script cannot express a
   clear at all (4 args required, address validated). Shipping an unverified revert
   is exactly what the delivery rule exists to prevent. Replaced with the honest
   GUI clear + a note that a --clear flag would be the real fix.

repo-lint 0 fail.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Office1 LAN IPv6 is LIVE and proven on the wire -- Stage 2 close-out C1 CLOSED ...

The last build item on Office1. Executed against the live edge, verified against
the kernel and the wire, not by {"result":"saved"}.

  scripts/opnsense-set-interface-v6.sh --commit 10.10.0.1 lan 2602:f3e2:f01:1 64
  POST /api/radvd/settings/addEntry {"entries":{...,"mode":"unmanaged"}}
  POST /api/radvd/service/reconfigure

PROVEN: address on the kernel (ifconfig, not the config file); radvd advertising
2602:f3e2:f01:/64 AdvAutonomous/AdvOnLink with no M/O flags; voffice1
autoconfigured ...:5054:ff:fe6a:87e5 by SLAAC + an RA-learned route; edge->voffice1
GUA ping 0.0% loss. The neighbour MAC matches voffice1's known Kea lease hwaddr.
No collateral damage: v4 10.10.0.1 intact, Kea DHCPv4 still serving udp/67, the
compose-net route still good.

mode=unmanaged is DELIBERATELY not the model's default. `stateless` sets the RA
Other-config flag, pointing clients at a DHCPv6 server -- and Kea DHCPv6 is
enabled=0 with no daemon running. The default would have advertised a server that
does not exist. Field names, the request key (addBase('entries','entries')), the
mode values and the apply endpoint were all READ OFF THE EDGE, not recalled.

OPERATOR RULING -- the v6 NAT was NOT built. A v4-to-v6 NAT (a second OPNsense, or
nginx) was proposed to simulate the v6 the lab will not forward. Withdrawn: it
contradicts D-101 ("native GUA routing, no NAT66"), D-115's amendment says the
missing egress is the upstream's problem and not ours, and a translation box is
precisely the component Roosevelt will NOT have -- maximum delta for zero proof.
nginx is an L7 proxy, not NAT, and proves nothing about RA/ICMPv6/Ceph-over-v6.
Ruling: configure IPv6 internally now; configure the IPv6 edge AFTER deployment.

TRAP recorded: voffice1 has forwarding=1 + accept_ra=0 and STILL autoconfigured --
netplan/systemd-networkd processes RA in USERSPACE, independent of the sysctl.

WAN v6 leg stays DEFERRED: re-measured today, v6 internet is 100% loss from vcloud
while v4 is fine. Internet GUA reachability remains UNPROVABLE in VR1.

repo-lint 0 fail; opnsense-set-interface-v6 harness 40/40.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>