Validate true blue/green deploy behavior for DO App Platform

[intel352]

Context

Recent gocodealone-multisite deploys exposed that App Platform deployment ACTIVE is not sufficient to mean custom-domain HTTPS is ready. workflow-plugin-digitalocean v2.0.15 now waits for custom domains to become active and externally reachable before wfctl infra apply --wait reports healthy.

That fixes the readiness gate, but it does not by itself prove zero-downtime behavior. During rollout, users may still see TLS/DNS/SSL errors if the DO App Platform custom domain is disrupted while an in-place update is progressing.

Latest validation evidence:

• Multisite deploy using workflow-plugin-digitalocean v2.0.15: https://github.com/GoCodeAlone/gocodealone-multisite/actions/runs/26287776784
• wfctl waited while gocodealone.tech custom domain was CONFIGURING and certificate validation was pending.
• Smoke started after wfctl --wait completed and passed immediately.
• Live endpoints returned 200 with valid TLS after deploy:
  • https://gocodealone.tech/healthz
  • https://www.gocodealone.tech/healthz
  • https://admin.gocodealone.tech/healthz

Problem

We need to validate whether the DO plugin's current blue/green implementation provides a true traffic handoff, or whether it still performs an in-place update of the production app after validating a green app.

Current concern from code inspection: the green app may be validated, but the switch path appears to update the blue app spec/image rather than routing traffic to the already-healthy green app. If that is accurate, it reduces risk but does not guarantee zero-downtime custom-domain behavior.

Desired outcome

workflow-plugin-digitalocean should provide a reusable deployment strategy that prevents users from receiving traffic on a new/reconfigured app until it is truly ready, including custom-domain HTTPS readiness.

Tasks

• Audit current App Platform deploy and blue/green drivers.
• Determine whether DO App Platform can support true blue/green traffic switching with custom domains directly.
• If direct App Platform custom-domain blue/green is not possible, design the reusable front-door strategy needed to support it.
• Add tests that distinguish in-place image updates from true traffic handoff semantics.
• Add rollout-time availability probes, not only post-rollout smoke checks.
• Document the supported guarantees and any DO platform limitations.
• Validate against gocodealone-multisite or another real app before closing.

Acceptance criteria

• The DO plugin has a documented, tested answer for whether current blue/green is true traffic switching or just prevalidated in-place deploy.
• wfctl --wait and DO plugin health checks include custom-domain HTTPS readiness where applicable.
• A deployment using the selected strategy does not mark healthy until the public custom domain is externally reachable.
• Any remaining downtime risk is explicit in docs and tracked as a separate implementation issue if not solved here.