dc0-activation: phase-04 network scripts MAAS_PROFILE-aware (DOCFIX-213, F3/D-138) + re-IP ruling-prep package ...

phase-04-network-create.sh + phase-04-network-verify.sh honour MAAS_PROFILE
(default admin=VR0/office1; VR1 overrides to the DC regional, e.g. vr1-dc0-region)
instead of hardcoding 'maas admin'. Fixes F3: the dc0 rack has openstack+cloud L3
but no maas profile, and the maas two-source gate needs both on one host. Operator
directive: each DC has its site regional maas; racks register up to the DC regional.
Harnesses extended with EXPECT_PROFILE proof (failability verified out-of-band).

Also lands docs/audit/reip-1013-ga-r5-ruling-prep-20260808.md (Task #6 background
analysis) + a CURRENT-STATE pivot pointer to it (L10 coupling).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Fg98z7QyzwYUs8fsWCn728

D-113(a2) step 1: thin OPNsense REST API client + harness ...

First delivery under the D-113 ruling (stay on OPNsense, move config off hand-authored
config.xml and onto the documented REST API).

  scripts/opnsense-api.sh        -- [--dry-run] <GET|POST> <api-path> [json-body]
  tests/opnsense-api/run-tests.sh -- offline harness, 21 PASS, no network, no real key

Gauntlet ALL GREEN (53 harnesses, was 52). repo-lint 0 fail.

Design decisions that the harness now enforces:

- THE SECRET NEVER REACHES ARGV. Credentials are read from a file and handed to curl via
  --config on STDIN. `curl -u key:secret` would put the secret in argv, where any user on the
  box can read it out of `ps`. Harness T9 stubs curl with an argv recorder and asserts the
  secret is absent from argv and present on stdin -- so a future "simplification" to `curl -u`
  turns the harness red. That case is the point of the file.
- The API host is NEVER inferred (hard rule 2): $OPNSENSE_API_HOST unset is a loud failure, not
  a silent default of 10.10.0.1 (T3).
- --insecure is deliberate and scoped: the edge's self-signed cert is REGENERATED ON EVERY BOOT
  (measured -- "Created web GUI TLS certificate" appears in the config revision trail after each
  reboot), so pinning it is pointless. Acceptable ONLY on the private lab LAN leg; never to be
  copied to a tenant-facing surface.
- Dry-run reads no credentials (T11), which is what lets the harness prove URL construction
  offline.

NOT RUN against the edge yet, and blocked on one thing: the API is alive (lighttpd on 443
answers 401) but root has 0 API keys. Minting one is a GUI action (System > Access > Users >
root > API keys), deliberately NOT automated -- writing apikeys into config.xml by hand is the
exact anti-pattern D-113 just retired. Key lands in ~/vr1-office1-creds/opnsense-api.txt,
operator-only, never read into agent context (SEC-007 covers that directory).

Proof-of-path once the key exists: drive yesterday's DHCP subnet through the API and confirm it
round-trips. If it does, the template retires to a minimal bootstrap config (sshd + root key +
console + apikey) and DHCP/firewall/interfaces move to the API. If it cannot express it, that is
the signal to revisit D-113.

Revert: git rm scripts/opnsense-api.sh && git rm -r tests/opnsense-api/ (nothing live touched).

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

Phase 3 updates