release: RELEASE-NOTES-TEMPLATE.md is never consumed by automation — release.yml uses generate_release_notes: true

[randlee]

Non-blocking follow-up for after 1.4.2 ships. Split out from #502, which covers the template's stale contents; this issue covers the fact that nothing reads the template at all.

Summary

release/RELEASE-NOTES-TEMPLATE.md is documented as a required release step but is not wired into any automation. Filling it in has no effect on the published GitHub Release.

Evidence

.github/workflows/release.yml, release job:

      - name: Create GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          tag_name: ${{ needs.gate-and-tag.outputs.release_tag }}
          generate_release_notes: true
          files: |
            release/*

generate_release_notes: true makes GitHub synthesize the release body from the commit/PR list. No step reads release/RELEASE-NOTES-TEMPLATE.md; no other workflow references it either.

RELEASING.md ("Release Notes") nonetheless instructs:

Fill out release/RELEASE-NOTES-TEMPLATE.md with the actual release summary before creating the GitHub release.

That is unactionable as written — the template cannot influence a body that is generated from commits. The only way curated notes reach the release today is a manual post-publish edit of the release body, which RELEASING.md does not document.

Why this matters beyond tidiness

A documented artifact that no automation consumes has no feedback loop, so it drifts silently. That is very likely how the stale Included Packages table in #502 (missing sc-sha on crates.io + PyPI, missing the Scoop channel) survived across releases without anyone noticing.

Options

1. Wire it up (preferred) — have the release job read the filled-in template into the release body via body_path:, dropping or supplementing generate_release_notes.
2. Document the reality — state plainly in RELEASING.md that release notes are auto-generated from commits, and that the curated template must be pasted into the release body as an explicit post-publish step.

Option 1 is preferred: it gives the template an automated consumer, so future drift surfaces as a failure rather than going unnoticed.

Scope note

Explicitly not a 1.4.2 blocker. Per team-lead, GitHub's auto-generated body is sufficient for 1.4.2 and no manual body-edit ceremony is being added mid-release. Contents-only fix for #502 lands with the 1.4.2 prep PR; this wiring question is picked up afterward.

Found during 1.4.2 release execution by publisher.