A small patch release that stops generated release notes from saying the
same thing three times, and keeps communique's own sponsor footer from
compounding on workflow reruns.

## Fixed

- **Reserve Highlights for genuinely broad releases** — The release-note
system prompt and the `submit_release_notes` tool schema have been
retightened so the model stops producing a `## Highlights` section that
just restates the categorized `## Added` / `## Fixed` bullets underneath
it. The opening summary is now capped at 1-2 sentences, Highlights are
gated on "roughly 10+ distinct user-facing changes or 4+ independent
headline themes", and the prompt explicitly assigns each section a
distinct job: the opening paragraph frames the release, Highlights (when
present) group broad themes for skimming, and categorized sections carry
the concrete PR links, authors, examples, and compatibility notes. The
prompt also tells the model directly to avoid saying the same change
three times. Patch and small minor releases should now skip Highlights
entirely instead of padding them out.
([#124](#124)) (@jdx)
- **Dedupe the sponsor blurb on release reruns** — communique's own
`release-plz` workflow appends a `## 💚 Sponsor communique` footer to
each GitHub release. If the workflow re-ran, or if communique itself
drafted notes that already included a sponsor section, the footer would
stack up. The `Append en.dev sponsor blurb` step is now idempotent: it
strips any existing `## 💚 Sponsor communique` section from the current
release body before appending the canonical en.dev blurb.
([#123](#123)) (@jdx)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk: this PR only bumps version metadata and updates generated
documentation/changelog; no runtime behavior changes are included in the
diff (aside from a potential `CHANGELOG.md` formatting glitch).
> 
> **Overview**
> Cuts the `v1.1.1` release by bumping the crate/CLI version from
`1.1.0` → `1.1.1` across `Cargo.toml`, `Cargo.lock`, the usage spec, and
generated CLI docs.
> 
> Updates `CHANGELOG.md` with a new `1.1.1` entry describing two fixes,
though the edit also leaves a **formatting issue** where the `1.1.0`
entry appears to run into the `1.0.4` header.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
82507c2. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

## Summary

- The `Append en.dev sponsor blurb` step in
[.github/workflows/release.yml](.github/workflows/release.yml) was not
idempotent. Under communique 1.1.x, the LLM reproduces a `## Sponsor hk`
section verbatim from the previous release's body into the new body, and
this step would then unconditionally append a second `## 💚 Sponsor hk`
block on top — visible in
[v1.44.2](https://github.com/jdx/hk/releases/tag/v1.44.2) (already
manually fixed via `gh release edit`).
- Strip any existing `## …Sponsor hk` heading (and everything after it)
from the live release body before appending the canonical blurb. Mirrors
[jdx/communique#123](jdx/communique#123).
- The regex `s/\n*^##[^\n]*Sponsor hk\b.*\z//ms` matches both the
no-emoji form (`## Sponsor hk`, which communique generates because of
`[defaults] emoji = false` in `communique.toml`) and the canonical `## 💚
Sponsor hk` form, so the step is self-healing on reruns.

## Why this differs slightly from the upstream communique fix

communique uses `s/\n*##\s+💚?\s*Sponsor communique\b.*\z//s`, which only
works when the offending duplicate also contains 💚. That happens to be
true in their repo because they don't set `emoji = false`. For hk, the
LLM-injected duplicate has no emoji, so the byte-mode `💚?` quantifier
(which makes only the last byte of the 4-byte UTF-8 sequence optional,
not the whole codepoint) fails to match. The simpler `[^\n]*` form is
byte-safe and matches both variants.

## Test plan

- [x] `actionlint .github/workflows/release.yml` passes
- [x] `yamllint .github/workflows/release.yml` passes
- [x] Manual dry-run: piping the live v1.44.2 body through the new regex
strips both sponsor sections cleanly, leaving `**Full Changelog**: …` as
the last meaningful line
- [x] Manual one-shot fix already applied to v1.44.2 release notes
(sponsor count: 1)
- [ ] Next tagged release produces a body with exactly one `## 💚 Sponsor
hk` section

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Low risk CI-only change that adjusts how GitHub release notes are
post-processed; main risk is accidentally stripping trailing content if
the regex matches unexpectedly.
> 
> **Overview**
> Makes the `Append en.dev sponsor blurb` step in
`.github/workflows/release.yml` idempotent by first fetching the current
GitHub release body and stripping any existing `## …Sponsor hk` section
(and everything after it) before appending the canonical sponsor blurb.
> 
> This prevents reruns/LLM-generated notes from producing duplicate
sponsor sections in published release notes.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
e9bed07. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>