Correct the workflow doc's status: it was materially FALSE and would misdirect work ...

docs/dc-dc-deployment-workflow.md is the first thing a fresh session reads. Its status claims
dated from 2026-07-09 and had drifted into being wrong. Corrected against MEASURED state.
Docs only; no code, no live system touched.

  gap #2      "UNVALIDATED -- no tofu binary"  -> OpenTofu v1.12.3 IS installed; tree validates
                                                 (root + 10/10 modules) and is partly APPLIED
                                                 (11 resources in state). But 2 modules were
                                                 BROKEN and had never been parsed (DOCFIX-194).
  gap #17     "no per-site ISP-uplink network  -> CLOSED FOR OFFICE1: office1-wan is live
               exists anywhere, for ANY site"     (virbr11, NAT, 172.30.1.0/24); the edge's WAN
                                                 sits on it at 172.30.1.2, egress verified. The
                                                 gap's own proposed answer (a dedicated per-site
                                                 uplink, NOT a mesh leg) is what got built.
                                                 DC1/DC2 STILL have none.
  opnsense-edge  "BUILT, UNVALIDATED"          -> BUILT, INSTANTIATED, RUNNING (routing, NAT,
                                                 egress, console, SSH, Kea DHCP on udp/67).
  config.xml tmpl "BUILT, fully tested"        -> SUPERSEDED by D-113(a2); a full push would now
                                                 CLOBBER live API-managed DHCP.
  netem-link  "BUILT, UNVALIDATED"             -> WAS BROKEN; fixed 2026-07-13 (DOCFIX-194).
  Stage 2     "NOT YET EXECUTED"               -> PARTIALLY EXECUTED.

THE TRAP THIS REMOVES: Stage 2's gate lists "NetBox authoritative" and "GitBucket serving" -- and
NetBox and GitBucket DO answer, at baldurkeep.com. But those are PRE-EXISTING services, NOT
Office1 headend VMs. Measured: office1-opnsense is the ONLY VM on the vcloud host. It would be
very easy to tick that gate as met and walk into Stage 3 with no headend at all. The corrected
State section now says this explicitly.

What actually remains of Stage 2 (the real critical path): the three headend service VMs
(MAAS-region, NetBox, GitBucket) do not exist. Blocked on a genuine decision, not on typing:
Option A (modules/cloudinit-vm) needs user_data/meta_data/network_config designed and an image
source chosen; Option B is manual virt-install, logged as debt. Both cloudinit-vm and base-image
now at least VALIDATE (DOCFIX-194) -- they never had before.

Revert: git revert this commit (restores the stale, false status claims).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01B6Fzre1CxCY8tzwFCudu57