[minor] Document Google-native publishing domains

infrastructure/cloud-compose.mdx

@@ -240,9 +240,9 @@ power-on budget and a 300-second backend-dial budget inside the 600-second
 Cloud Run request ceiling. Its hosted GCP gate sends one request, verifies the
 VM reaches `RUNNING`, follows a changed ephemeral external address after a
 stop/start, then performs host-level and application checks. Those direct-path
-budgets do not fit behind non-Enterprise Cloudflare's 120-second read limit;
-the managed router uses a separate pre-dispatch retry contract documented in
-[Security and Operations](/platform/security-operations).
+budgets are intentionally longer than the managed platform's bounded router
+request; the managed router uses a separate pre-dispatch retry contract
+documented in [Security and Operations](/platform/security-operations).
 
 In releases that expose the hardened power-management contract, enabling it
 requires explicit original-client CIDRs in

infrastructure/current-release-status.mdx

@@ -38,7 +38,7 @@ The table deliberately does not invent an image digest, template commit, signatu
 
 | Integration | Status | Gate that remains |
 | --- | --- | --- |
-| Cloudflare and load balancer to shared Cloud Run router to private per-site PPB | Blocked / preview | PPB `0.5.1` is available, but the exact router image, API/router integration, managed Terraform pins, private-origin, client-IP, authorization-preservation, split timeout, Direct VPC, and rollback canaries still need promotion as one managed set. |
+| Cloud DNS and Certificate Manager through the global load balancer, Cloud Armor, shared Cloud Run router, and private per-site PPB | Blocked / preview | PPB `0.5.1` is available, but the exact edge-controller and router images, DNS delegation, certificate-map lifecycle, API/router integration, managed Terraform pins, private-origin, client-IP, authorization-preservation, split timeout, Direct VPC, and hosted canaries still need promotion as one managed set. Cloud CDN remains disabled. |
 | Organization Vault three-image runtime | Blocked / preview | The verified-publisher desired state is merged, but the public GAR writer migration has not passed a successful central Terraform apply and protected-workflow publication canary; the Vault Init GAR upload still fails closed. Apply and verify that central state, publish and verify the independently versioned `vault-server`, `vault-init`, and `vault-proxy` manifests, release the sitectl-admin digest resolver and exact tag-commit/signature gate, pin all three immutable GAR manifests, and pass the API, Terraform, initialization, recovery, and rollback gates. A source release, local candidate, or reserved version is not an aggregate runtime release. |
 | Canonical API image set and production VM resolver | Blocked / preview | Merge the hosted post-CI publisher and `sitectl admin terraform api-compose-images`; publish the exact protected-main run to GHCR plus the appropriate private or public GAR repository; verify every digest's reusable-workflow identity, caller repository/ref/SHA, and caller-workflow annotation; and prove fresh VM bootstrap plus in-place refresh with the four verified private-GAR Compose images, the checkout detached at the publication commit, and legacy boot-disk discovery that fails on ambiguity. |
 | Separate request-serving API and `api-worker` Cloud Run services | Preview | Release the managed worker deployment and prove identity bootstrap, database connectivity, readiness, rollout, rollback, and removal of any temporary migration privilege. A process boundary in source or Compose is not proof of this Cloud Run topology. |

infrastructure/release-compatibility.mdx

@@ -125,56 +125,42 @@ copy. Images consumed by LibOps GCP runtimes also receive a GAR copy:
 `api` (also tagged as `dash`), `api-init`, `api-vault-agent`, and
 `control-plane` use the private API-project repository; `terraform-runner`,
 `gcp-vm-ip-controller`, `controller-ingress`, and `site-controller` use shared
-public GAR; and `cloudflare-ingress-router` uses the separate
+public GAR; and `site-router` uses the separate
 shared-infrastructure GAR repository. The independently owned `vault-server`
 image is not built or published by the API workflow.
 
-The Terraform runner has a separate provider-mirror build path so one large
-provider build does not hide which provider failed or exhaust one native
-runner. It gives every pinned Terraform provider its own lane:
+The Terraform runner consumes official provider packages through Terraform's
+authenticated Registry mirror command. Its dedicated mirror root pins the
+providers required by the embedded stacks:
 
 | Provider lane | Contents |
 | --- | --- |
 | `google` | Google provider |
 | `google-beta` | Google Beta provider |
 | `vault` | Vault provider |
-| `cloudflare` | Cloudflare provider |
 | `time` | Time provider |
 
-On a pull request, each lane is built and scanned separately for native
-`linux/amd64` and `linux/arm64`. The jobs do not receive package, GAR, or OIDC
-publisher authority. They upload one-day, run-ID-scoped mirror artifacts, and
-the matching architecture's Terraform-runner job downloads only artifacts
-from that workflow run. It validates the exact allowlisted files, executable
-modes, ELF architectures, Go toolchain, and security-sensitive dependency
-versions before assembling the runner. The completed runner then proves that
-each embedded stack can initialize and validate without downloading providers.
-These artifacts are an internal handoff between credential-free PR jobs, not
-published packages or a release channel.
+The committed provider lockfile contains the upstream authenticated checksums
+for `linux/amd64` and `linux/arm64`. Pull-request jobs build the complete
+Terraform runner for both native architectures without package, GAR, or OIDC
+publisher authority, scan it, and prove every embedded stack initializes and
+validates with network provider installation disabled. The workflow does not
+compile providers, publish intermediate provider images, or replace upstream
+binaries to chase dependency scanner findings. Provider fixes arrive through
+reviewed upstream releases and lockfile updates.
 
 After required CI succeeds for the exact current `main` commit, the protected
-publisher builds the same five multi-platform lanes. Their intermediate
-images are GHCR-only, scanned and keylessly signed build products named
-`terraform-providers-google`, `terraform-providers-google-beta`, and
-the corresponding `terraform-providers-vault`,
-`terraform-providers-cloudflare`, and `terraform-providers-time` packages. The
-workflow uses the stable
-`sha-<40-character-commit>-run-<workflow-run-id>-provider` selector for those
-five intermediates. Before building the final runner, it resolves each
-intermediate to an immutable digest, requires exactly the expected amd64 and
-arm64 manifests and distinct digests, verifies each keyless signature against
-the pinned shared publisher identity, and confirms that the selected commit is
-still current `main`. Only those verified digest references enter the final
-Terraform-runner build.
+publisher builds the same final multi-platform runner directly from the
+reviewed Dockerfile and lockfile. There is no provider-image handoff between
+jobs or registries.
 
 The deployable images, including the final `terraform-runner`, use the
 `sha-<40-character-commit>-run-<workflow-run-id>-attempt-<workflow-attempt>`
 selector. The runner is scanned, signed, and published to both GHCR and shared
 public GAR. Deployment resolves every deployable image name independently and
-passes only digest references; it does not deploy or pin the intermediate
-provider images. These signatures bind the reviewed publisher identity to the
-published digests. They are not SLSA provenance or an attestation of the full
-build-material graph.
+passes only digest references. These signatures bind the reviewed publisher
+identity to the published digests. They are not SLSA provenance or an
+attestation of the full build-material graph.
 
 Before this API publication path can be promoted, the admin plugin must resolve
 every selected API bundle image and the independently released Vault server to

platform/adoption-model.mdx

@@ -162,7 +162,7 @@ must not manage a resource owned by another root.
 The shared-router/private-PPB integration is a target architecture and is not generally released in the [current status snapshot](/infrastructure/current-release-status). The ownership boundary remains valid, but the linked router identity, canonical client-IP, and timeout details must not be treated as the current production topology until their release gate is complete.
 </Warning>
 
-In that target path, controller and site delivery use private network traffic but remain authenticated. Shared project state owns the Cloud Run service identity, network-use permissions, and regional network capacity; runtime state owns instance-scoped power grants and VM firewall rules. The public site path still enters through the declared Cloudflare and load-balancer edge because Direct VPC provides Cloud Run **egress**, not service ingress. See [Security and Operations](/platform/security-operations) for the target router-to-PPB identity, canonical client-IP, subnet, startup, and timeout contracts.
+In that target path, controller and site delivery use private network traffic but remain authenticated. Shared project state owns the Cloud Run service identity, network-use permissions, and regional network capacity; runtime state owns instance-scoped power grants and VM firewall rules. The public site path still enters through Cloud DNS, the global external Application Load Balancer, Cloud Armor, and the shared router because Direct VPC provides Cloud Run **egress**, not service ingress. See [Security and Operations](/platform/security-operations) for the target router-to-PPB identity, canonical client-IP, subnet, startup, and timeout contracts.
 
 ## Responsibility changes by adoption layer