Cut v0.3.0: the Release-As footer was dropped from #60 and #62

[abienkowski]

Problem

v0.3.0 was meant to be cut by a Release-As: v0.3.0 footer in the squash body of #60, and then of #62 (closes #61). Both merges used the repo default squash body, so the footer never reached main.

• fix(release): derive the version bump from commit types (#54) #60 shipped as v0.2.27.
• The release run for docs: say the default squash body drops footers; correct the #54 example (#61) #62 (37709033894) was cancelled before its version job, so nothing was tagged.

The "Worked Examples" table in docs/release-versioning.md now wrongly says #61 ships as v0.3.0.

Proposed solution

Correct the worked example: #62 also lost its footer and its release was cancelled. Merge this fix with a squash body that carries Release-As: v0.3.0, using gh pr merge --squash --body-file. Its release covers v0.2.27..HEAD, which includes #62, so #62 and this fix ship together as v0.3.0.

Alternatives considered

• Footer on the Routing parity: TS path-wide exec deny; Go matchEndpoint accepts endpoint subpaths #49 merge. Rejected by the maintainer. v0.3.0 should be cut on its own, ahead of Routing parity: TS path-wide exec deny; Go matchEndpoint accepts endpoint subpaths #49.
• Empty commit. Rejected: GitHub cannot squash-merge a PR with no file changes.

[abienkowski]

Reopened. #64 was merged with an empty squash body, so the footer missed main for the third time. Release run 37774150988 was cancelled before tagging. Root cause: the footer only ever existed in a separate merge-message file. The branch commit had no body, and GitHub's default squash message for a single-commit PR is that commit's own message. Fix: put Release-As: v0.3.0 in the branch commit's message itself, so the default squash carries it, and update the doc to recommend that.