release/RELEASE-NOTES-TEMPLATE.md 'Included Packages' table is stale — missing sc-sha (crates.io + PyPI) and Scoop

[randlee]

Summary

The release-notes template's Included Packages table does not match the actual publish surface defined in release/publish-artifacts.toml and RELEASING.md. Anyone filling it out for 1.4.2 would under-report what shipped.

Current template

| Package | Version | Channel |
|---------|---------|---------|
| `sc-composer` | <VERSION> | crates.io |
| `sc-compose` | <VERSION> | crates.io · Homebrew · Winget · GitHub Releases |
| `sc-compose` (Python) | <VERSION> | PyPI |

Actual surface

release/publish-artifacts.toml declares three crates and two Python distributions:

• crates: sc-sha (publish_order 1), sc-composer (2), sc-compose (3)
• python_distributions: sc-sha, sc-compose
• channels: pypi, homebrew, scoop (randlee/scoop-bucket), winget

RELEASING.md's Overview table lists six channels including Scoop.

Missing from the template: sc-sha on crates.io, sc-sha on PyPI, and the Scoop channel on sc-compose.

Required fix

Update the table in release/RELEASE-NOTES-TEMPLATE.md to match the manifest:

| `sc-sha` | <VERSION> | crates.io · PyPI |
| `sc-composer` | <VERSION> | crates.io |
| `sc-compose` | <VERSION> | crates.io · PyPI · Homebrew · Scoop · Winget · GitHub Releases |

Ideally this table should be generated from release/publish-artifacts.toml rather than hand-maintained, since the manifest is the declared SSoT and this is the second doc found drifting from it (see also #500).

Found during 1.4.2 release verification by publisher.

[randlee]

Additional defect on the same file, found while tracing the production publish path — the template is never actually consumed by any automation, so fixing its contents alone won't make it reach users.

.github/workflows/release.yml's release job creates the GitHub Release with:

      - 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 means the release body is auto-generated by GitHub from the commit/PR list. Nothing reads release/RELEASE-NOTES-TEMPLATE.md.

But RELEASING.md states:

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

That instruction is unactionable as written — filling the template in before the workflow runs has no effect on the published release body. The only way the curated notes reach the release is a manual post-publish edit of the release body, which RELEASING.md never mentions.

So there are two things to fix here, not one:

1. The table contents (original issue).
2. The template→release wiring: either have the release job read the filled template into the release body instead of generate_release_notes: true, or correct RELEASING.md to state plainly that the notes are auto-generated and the curated template must be pasted into the release body as an explicit post-publish step.

Option 1 is the better fix — a documented artifact that no automation consumes will drift again, which is how this file got stale in the first place.

Found during 1.4.2 release execution by publisher.