ci: publish GitHub release notes from the proposal PR

.github/workflows/release.yml

@@ -49,9 +49,34 @@ jobs:
         run: |
           content=`cat ./package.json | tr '\n' ' '`
           echo "json=$content" >> $GITHUB_OUTPUT
-      - run: |
-          git tag v${{ fromJson(steps.pkg.outputs.json).version }}
-          git push https://x-access-token:${{ steps.octo-sts.outputs.token }}@github.com/${{ github.repository }}.git v${{ fromJson(steps.pkg.outputs.json).version }}
+      - name: Tag release
+        run: |
+          version="${{ fromJson(steps.pkg.outputs.json).version }}"
+          remote="https://x-access-token:${{ steps.octo-sts.outputs.token }}@github.com/${{ github.repository }}.git"
+          # Idempotent, so that a rerun after a partial failure can still
+          # repair the tag and the release notes.
+          if git ls-remote --tags "$remote" "v$version" | grep -q "v$version"; then
+            echo "Tag v$version already exists, skipping"
+          else
+            git tag "v$version"
+            git push "$remote" "v$version"
+          fi
+      - name: Release notes
+        env:
+          GH_TOKEN: ${{ steps.octo-sts.outputs.token }}
+          VERSION: ${{ fromJson(steps.pkg.outputs.json).version }}
+        run: |
+          # The release notes are the body of the proposal PR, looked up by its
+          # head branch. This resolves even after the branch is deleted on merge.
+          notes="$RUNNER_TEMP/v$VERSION.md"
+          gh pr view "v$VERSION-proposal" --json body --jq .body > "$notes"
+          # v5.x is currently the only release line. Once a second one ships,
+          # --latest has to be decided per branch rather than hardcoded.
+          if gh release view "v$VERSION" > /dev/null 2>&1; then
+            gh release edit "v$VERSION" --title "$VERSION" -F "$notes" --latest
+          else
+            gh release create "v$VERSION" --target "${{ github.ref_name }}" --title "$VERSION" -F "$notes" --latest
+          fi
 
   publish_dev:
     needs: build