Release-notes backfill doesn't republish the devsite changelog, leaving entries permanently empty

Symptom

Four entries on https://dev.dotcms.com/docs/reference/releases/product-versions/changelogs render with a title, availability date and docker tag but no release notes: 26.08.28-01, 26.08.31-01, 26.08.31-02, 26.09.02-01.

The GitHub releases for all four have correct bodies (2.2k–6.8k chars). The site does not.

How they got that way

1. Generate release notes with Claude failed on each of these runs, so Update release description was skipped and the GitHub release body stayed empty.
2. Changelog Site Publish ran anyway and succeeded, publishing an entry with empty releaseNotes. Log signature: Fetched release notes (1 lines). — versus (20 lines). on the healthy 26.09.03-01 run.
3. The 2026-09-03 04:00 backfill repaired all four GitHub release bodies. The site was never touched.

Step 2 happens because the non-empty guard doesn't catch it:

gh release view "$RELEASE_TAG" --repo "$REPO" --json body --jq .body > /tmp/site-release-notes.md
if [ ! -s /tmp/site-release-notes.md ]; then   # cicd_comp_changelog-site-publish-phase.yml:94

--jq .body on an empty body emits a bare newline, so the file is 1 byte, not 0, and -s passes. Reproduced against v26.08.19-03: bytes=1 lines=1 → -s GUARD PASSES.

Step 3 happens because cicd_ai-release-notes-backfill.yml has exactly one job, Generate Notes. It writes the GitHub release body and stops. There is no path from a backfill to the site, so once an entry is published empty it stays empty forever.

Scope of this issue

Close the backfill gap — make the backfill publish to the site as well, so a repaired GitHub release body always reaches dev.dotcms.com. This also makes the backfill the general repair tool for any site entry that is empty, stale, or wrong.

The -s guard is a separate (and now less consequential) defect — tracked separately, not fixed here.

Two things the wiring has to get right

Docker image. The release pipeline gets docker_tags from its deployment phase; a backfill has no deployment to read from and must recover them from Docker Hub. Matching "tag contains _" is wrong — 26.08.28-01_tainted and 26.08.31-01_tainted both exist and sort ahead of the real tag. Match a 7-hex sha suffix. Verified against all four original runs:

Availability date. The publish phase hardcodes --released-date "$(date -u +%F)", and publisher.py:154 writes that straight through on the update path. Backfilling 26.08.28-01 today would relabel it "Available: Sep 3, 2026". The phase needs an optional released_date passthrough; the backfill sources it from the release's published_at.

Acceptance criteria

• Dispatching the backfill for a current-track tag regenerates the GitHub release body and republishes the site entry.
• The republished entry keeps its original availability date and its sha-suffixed docker tag.
• CLI / LTS tags skip the site publish, matching the release pipeline's exclusion.
• A backfill whose site publish fails reports failure (the release pipeline's allow_failure is deliberate there; a backfill has no software release to protect).

Start with cicd_ai-release-notes-backfill.yml and its Generate Notes job, then inspect cicd_comp_changelog-site-publish-phase.yml and publisher.py:154 for publish and date handling. Verify Docker Hub tag recovery, original-date preservation, current-track exclusion, and failure propagation by dispatching or testing a backfill.