Document the release process #543

What problem does this address?

The release process isn't written down anywhere. The only documented step is the docs deploy in CONTRIBUTING.md ("as part of cutting a release"). Everything else lives in people's heads and in past PRs like #533.

That gets riskier with translations (#540). Once the translate.wordpress.org pipeline lands, each release needs npm run i18n:download in the version-bump PR. If someone skips it, the build silently ships old translations or none, and nothing fails.

What is your proposed solution?

A RELEASING.md with the real steps. Pieced together from #533, so it needs confirming:

1. Open a PR that bumps "version" in package.json and package-lock.json. Run npm run i18n:download from the repo root, commit src/languages/, and paste the coverage table into the PR.
2. Merge. Buildkite builds the signed artifacts.
3. Tag the release (vX.Y.Z, betas as vX.Y.Z-beta.N).
4. Publish the GitHub release with notes and artifacts.
5. Deploy the docs: gh workflow run docs.yml --ref trunk -f ref=vX.Y.Z.

Also worth considering: a CI check on version-bump PRs that runs npm run i18n:download and fails if src/languages/ doesn't match translate.wordpress.org, so the translation step can't be skipped silently.

Related: #540, #541.