docs(changelog): move this PR's entry into a fragment

The fragment convention landed on main in #11215 while this PR was open: a PR
writes changelog.d/<slug>.md and leaves CHANGELOG.md alone.

The one CHANGELOG.md edit that stays is not this PR's own entry but the
correction of a PREVIOUS one — #11207's frontend bullet still says the API
pushes :latest alongside the deploy, which is exactly what this PR changes.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UEScQMZFvxxNNyNJYryfa3

Author: MarkusNeusinger

CHANGELOG.md

@@ -290,8 +290,9 @@ aggregate instead: an italic *Catalog* line at the end of the version section an
   traffic** — `app/cloudbuild.yaml` now follows the same candidate-rollout pattern as
   `api/cloudbuild.yaml`: deploy with `--no-traffic --tag=candidate
   --revision-suffix=b$BUILD_ID`, smoke the candidate on its tag URL, then `update-traffic`
-  to exactly that revision (the chains are not identical — this one pushes `:latest` only
-  after the promotion, where the API still pushes it alongside the deploy). The service
+  to exactly that revision. (The chains were not identical at the time — this one pushed
+  `:latest` only after the promotion, where the API still pushed it alongside the deploy;
+  the API caught up in a later entry of this same section.) The service
   carries the whole crawler path in `app/nginx.conf` — the `$is_bot` map, the `location =`
   bypasses, the `@seo_proxy` upstream — and that is the file whose breakage served every
   bot an HTTP 502 for four weeks in 2026 while humans, Plausible and CI all saw a healthy

changelog.d/api-deploy-edges.md

@@ -0,0 +1,20 @@
+### Changed
+
+- **The API deploy gets the three edges the frontend deploy already had** — the candidate
+  rollout `api/cloudbuild.yaml` invented was then improved in `app/cloudbuild.yaml` (#11207)
+  and the improvements never came back. Three of them do now. `:latest` waits on `promote`
+  instead of on `build-image`: it used to reach the registry before the candidate had been
+  deployed, let alone smoked, so a build whose smoke failed still left `:latest` naming the
+  image that failed it. The smoke re-asserts the `candidate` tag AFTER its probes as well as
+  before — the tag is shared across builds, so a concurrent one could move it mid-smoke and
+  this build would promote a revision it only believed it had probed; a competing build only
+  ever tags its own revision, so ours at both ends means the tag was never reassigned while
+  the probes ran. That detects an observed reassignment rather than proving where a probe
+  landed: `status.traffic` is control-plane state, and tag-URL propagation can lag it, which
+  is the residual `app/cloudbuild.yaml` already documents at its own smoke step. And the
+  probes stop piping into `grep -q`, which exits at the first match and SIGPIPEs
+  curl — the form only ever passed because `-ceu` carries no `pipefail`, so a later hardening
+  pass adding it would have turned every deploy red. They go through the same `expect` helper
+  `app/cloudbuild.yaml` uses, which fetches to a file and names the probe and the missing
+  needle when it fails; `/health` keeps a bare variant because reaching it without the origin
+  header is exactly what its gate exemption has to prove. (#11212)