fix(release): full channel changelog in GitHub release notes

[Wibias]

Summary

• Release notes for both preview and latest now keep GitHub generate-notes PR categories and append a ## Commits section from the channel-scoped previous tag (branch merges + direct commits that PR-only notes omit).
• Create and edit paths both use the same --notes-file body so republishing a tag gets the same full notes.
• Contract test asserts the commits log and that --generate-notes is no longer used alone on create.

Test plan

• bun test tests/ci-workflows.test.ts
• Next preview/latest workflow_dispatch publish: verify release body has PR categories, Commits list, and Full Changelog compare link

Summary by CodeRabbit

• Improvements

  • GitHub releases now consistently generate complete release notes from pull request content using a dedicated notes document.
  • Notes include a regenerated single “Full Changelog” compare link and a curated “Commits” section for the relevant range.
  • Release creation behavior is now uniform, with prerelease handling supported and tagging performed after notes are assembled.

• Tests

  • CI assertions were expanded to verify the release-notes generation flow, commit formatting/range, and that note-generation failures are not silently ignored.

[Wibias]

Dual review (security + bugs/edge cases)

CodeRabbit threads addressed on 355320d0 (see disposition below). Independent second look after those fixes.

CodeRabbit disposition

Finding	Action
Fail closed on generate-notes (|| true)	Fixed — API failure aborts the step
Remove --max-count=100 on first-channel history	Declined — no previous channel tag means unbounded repo history; keep a 100-commit cap to stay within GitHub release body limits. Channel deltas (the normal path) remain uncapped via ${previous_tag}..${GITHUB_SHA}
Unreachable gh release edit vs preflight	Fixed — edit path removed; create-only matches preflight
Strengthen contract tests	Fixed — create/commit_range/no-edit/no-soft-fail assertions; notes-before-tag order check

Extra fix from this review: assemble notes before git tag/git push so a notes API failure does not leave a remote tag that preflight then blocks on retry.

Security

Verdict: merge-ready for security (no blockers).

Checked:

• Inputs still reach the shell only via env: (no ${{ inputs.* }} in run:)
• No permission / token scope expansion; still contents: write + github.token
• Fail-closed notes improves metadata integrity vs silent empty PR categories
• Create-only removes the only path that could overwrite an existing release’s notes
• Commit subjects in notes are ordinary public changelog risk (merge + maintainer dispatch); not newly elevated

Bugs / edge cases

Verdict: merge-ready after the notes-before-tag reorder. Remaining residuals are operational, not blockers:

1. npm may already be published if the GitHub Release step fails later (pre-existing ordering: Publish → registry smoke → Create release). Manual gh release create recovery still needed in that case; not introduced here.
2. HTTP 200 with empty body from generate-notes still creates a release with Commits + compare link only. Acceptable; true API failures fail closed.
3. PR section + Commits section overlap (merge commits / PR titles appear twice) is intentional for the “full channel log” goal.

Checks

• bun test tests/ci-workflows.test.ts green locally after both follow-ups