Keep draft-spec work on a next branch, with backport and forward-port rules #1525

The SDK needs a written rule for which branch carries which spec, so that draft-spec work doesn't ship in stable releases.

Problem

main releases the 9.x line on AdCP 3.2.x: src/adcp/ADCP_VERSION is 3.2.1, and release-please cuts 9.0.0-beta.N from it. main also carries experimental AdCP 3.3 identity code written to open drafts (#1502). #1514 and #1523 add more, aligned to adcontextprotocol/adcp#7894, #8162, #8168, #8169, and #8170. Those drafts change until 3.3 is ratified, so every draft change lands in a 3.2.x release, and the 9.0 line can't go stable while part of it tracks drafts.

The repo already has most of the model. release/7.x and release/8.x carry the older majors, and release-please runs on release/8.x. What's missing is a branch for draft-spec work and a rule for moving fixes between branches.

Proposal

Use the following branches:

Move changes between branches with these rules:

• A fix lands on main first. A maintainer then backports it to each release/N.x that needs it.
• next takes main regularly, through a merge or a forward-port PR, so it doesn't drift.
• A change that only draft-spec work needs stays on next.
• When a spec version is ratified, next merges into main, and the next major releases from main.
• Labels such as backport release/8.x and forward-port next mark PRs that need a port. A backport action can open the port PRs.

Steps

1. Create next from main, and add a release-please configuration for it.
2. Retarget fix(identity): align AdCP 3.3 agent identity with the final spec and the Go and TS SDKs #1514 and refactor(signing): RFC 9421 on http-message-signatures; align Web Bot Auth with adcp#7894 #1523 to next.
3. Move feat(identity): add experimental AdCP 3.3 agent identity #1502 to next before 9.0.0-beta.4 (chore(main): release 9.0.0-beta.4 #1465) ships. It isn't in a release yet.
4. Write the rules in RELEASING.md, or in a section of CONTRIBUTING.md.

adcp-go and adcp-client have the same situation with their 3.3 identity work, tracked in adcontextprotocol/adcp#8118. If this model works here, they can adopt it too.