chore: skip auto-tagging in release-please; manual gh release create stays the gate

[StefanSteiner]

Summary

Adds "skip-github-release": true to release-please-config.json at both the top level and per-package level. release-please will continue to open chore: release main PRs with the CHANGELOG / version bumps / manifest updates, but will not auto-create the GitHub Release / git tag when those PRs merge. The maintainer creates the tag manually via gh release create, which fires release.yml → crates.io publish.

Why

crates.io and npm are immutable. Once cargo publish succeeds, the version is permanent — cargo yank only marks it "don't pick by default" without freeing the version slot. npm is similar (unpublish only works within 72 hours and nukes downstream caches).

The manual tag step is the only maintainer-controlled checkpoint between merging the release PR and permanently publishing the version. Everything before is reversible (revert PRs, edit CHANGELOG, close release-please PRs); everything after is forever.

How we discovered this property

During the v0.3.0 release pipeline, release-please failed to auto-tag after the release PR (#80) merged — the upstream issue is googleapis/release-please#1946 ("untagged, merged release PRs outstanding - aborting"). Recovery required a manual gh release create + label edit:

gh release create v0.3.0 \
  -R tableau/hyper-api-rust \
  --target a086806a... \
  --title "v0.3.0" \
  --notes-file <changelog-section> \
  --latestC

gh pr edit 80 --remove-label "autorelease: pending" --add-label "autorelease: tagged"

That recovery worked cleanly and turned out to be the right shape for the workflow. The human checkpoint between manifest-bump and crates.io publish caught is valuable on its own: even if release-please fixes #1946 upstream, we want the manual step. Better to codify it than to depend on a bug staying broken.

What this changes

• ✅ release-please still opens chore: release main PRs on every push to main with conventional commits.
• ✅ release-please still updates CHANGELOG, manifest, and Cargo.toml workspace versions when those PRs merge.
• ❌ release-please never creates the GitHub Release / git tag.
• ✅ Maintainer manually runs gh release create vX.Y.Z --target <merge-sha> ... to ship.
• ✅ release.yml fires on the manually-created release: published event, unchanged from today.

What this costs

• Every release is now manual — including patch releases (v0.3.1, v0.3.2, etc.), not just major-version bumps.
• The tag-creation procedure must be documented (filed as #83) so the next maintainer doesn't have to reverse-engineer the gh commands from this issue's history.
• The autorelease: pending → autorelease: tagged label promotion is now manual too. Skipping it doesn't break anything functionally, but release-please will keep proposing the same version until the label flips.

Schema verification

skip-github-release is documented in the release-please config schema at both:

• Top-level $.properties.skip-github-release (acts as default)
• Per-package $.definitions.ReleaserConfigOptions.properties.skip-github-release (overrides default)

Setting both for defense-in-depth and explicit intent, matching the bump-minor-pre-major pattern from #79.

Why not just rely on #1946 upstream

The issue is open and actively discussed; if/when fixed (release-please-action v5.x patch or v6), our flow would silently resume auto-tagging and the human checkpoint would disappear without anyone noticing. Codifying the manual step makes the design intent durable.

Test plan

• JSON valid (python3 -m json.tool passes)
• Schema field placement verified against release-please's own JSON schema
• After merge: next push to main triggers release-please workflow
• After merge: release-please opens a chore: release main PR (e.g. for v0.3.1 if any patches land)
• After merge: merging that PR does NOT auto-create a GitHub Release
• After merge: maintainer can run gh release create vX.Y.Z --target <sha> ... to ship

Closes follow-up from #82 (closed in favor of this approach).