Automate patch release post-publish steps

[alfonso-noriega]

WHY are these changes introduced?

Patch releases currently require several manual steps after CI publishes to npm: creating the git tag, opening the GitHub Release, and running `pnpm post-release`. These are mechanical and can be automated, reducing the patch release process to just two human decisions: the cherry-pick PR review and the Homebrew/docs PR review.

WHAT is this pull request doing?

`bin/post-release`:

• Skips the `dev github print-auth` and `git status` checks when running in CI — `withOctokit` already picks up `GITHUB_TOKEN` automatically so these guards are not needed there.
• Adds `--skip-notification` flag — patch releases do not send notifications.

`.github/workflows/release.yml`:
Adds two steps after publish that only fire on `stable/*` branches:

1. Creates and pushes the git tag, then opens the GitHub Release linking to the CHANGELOG.
2. Runs `pnpm post-release --skip-notification` to open the Homebrew and docs PRs.

Updated patch release steps

Before (7 steps):

1. Open a cherry-pick PR against `stable/X.Y` and merge it.
2. Locate and merge the "Version Packages - X.Y" PR — verify it is patch-only.
3. CI publishes to npm.
4. `git tag X.Y.Z && git push --tags`
5. Create GitHub Release manually.
6. Run `pnpm post-release` from the stable branch; close the notification PR.
7. Update Observe SLOs and error management rules.

After (4 steps):

1. Open a cherry-pick PR against `stable/X.Y` and merge it.
2. Locate and merge the "Version Packages - X.Y" PR — verify it is patch-only.
3. CI publishes to npm, creates the git tag, opens the GitHub Release, and opens the Homebrew and docs PRs automatically.
4. Review and merge the Homebrew and docs PRs.
5. Update Observe SLOs and error management rules.

How to test

The workflow steps can only be fully exercised by a real publish on a stable branch. However:

Test `post-release` changes locally:

Verify the CI path skips the `dev` auth check and notification PR:
```bash

From a stable branch, with a clean or dirty working directory:

CI=true pnpm post-release --skip-notification

Expected: skips git status check, skips dev auth check, skips notification PR, opens Homebrew + docs PRs

```

Verify the flag is required to suppress the notification (i.e. without the flag it still creates it):
```bash
CI=true pnpm post-release

Expected: opens Homebrew + docs + notification PRs

```

Verify the workflow condition logic:

The two new steps only fire when both conditions are true:

• `steps.changesets.outputs.hasChangesets == 'false'` — a publish actually happened
• `startsWith(github.ref_name, 'stable/')` — we are on a stable branch, not `main`

You can verify this by triggering the workflow manually on `main` after a publish and confirming the new steps are skipped.

End-to-end test:

Cherry-pick a trivial fix to `stable/X.Y` with a `patch` changeset, merge the resulting "Version Packages" PR, and confirm CI creates the tag, GitHub Release, and Homebrew/docs PRs without manual intervention.

[alfonso-noriega]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Automate patch release post-publish steps #7308 👈 (View in Graphite)
• Make Homebrew versioned formula generation dynamic #7310
• Prepare semver support #7307
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.