Release docs: default squash body drops Release-As/BREAKING CHANGE footers; cut v0.3.0

[abienkowski]

Problem

#60 (closes #54) was meant to cut v0.3.0 using a Release-As: v0.3.0 footer in its squash body. It was merged with GitHub's default squash body, which in this repo is the commit list (squash_merge_commit_message: COMMIT_MESSAGES). That body has no footer, so the release pipeline correctly computed a patch and shipped v0.2.27. Run 37704069768 logs: Latest tag: v0.2.26; range: v0.2.26..HEAD, bump=patch, tag=v0.2.27.

Two consequences:

• The docs are now wrong. The "Worked Examples" table in docs/release-versioning.md says Release pipeline always bumps patch; AGENTS.md claims versions derive from commit types #54 ships as v0.3.0.
• The merge guidance is incomplete. "Guidance for Whoever Squash-Merges" does not say that the repo default leaves out any footers written in the PR description, so BREAKING CHANGE: / Release-As: must be added at merge time.

Proposed solution

• Update docs/release-versioning.md:
  • Say that the default squash body is the commit list.
  • Recommend gh pr merge <N> --squash --subject … --body-file <file> when footers matter.
  • Correct the Release pipeline always bumps patch; AGENTS.md claims versions derive from commit types #54 row: shipped as v0.2.27; v0.3.0 is cut by this follow-up.
• This PR's squash body carries Release-As: v0.3.0. The pipeline then cuts v0.3.0, which is the version intended for the breaking changes that shipped as patches (feat!: dockerd-parity listening socket, Unix path only #47 in v0.2.22, Percent-encoded container names: Go routes on the decoded path, Rust/TS on the raw path #53 in v0.2.26).

Alternatives considered

• Switch the repo default to PR_BODY. Rejected (maintainer decision). It changes every PR's commit body to the PR template, with its checkboxes and evidence. Documenting the step keeps the history as it is.
• Stay on v0.2.x. Rejected. The version line should reflect the breaking changes.