Re-establish the release process

Currently the release process involves mainly a dev branch (`next`), and a current-version branch. In the past we also did release branches, but recently we've been cutting RC releases from `next`. RC4 failed to publish because some published crates were based on unpublished deps. Because `next` is a dev branch, we cannot run a check to see whether the workspace is publishable (because most of the time we depende on unreleased crates).

There are a few things to review with the current release process:

* `release/*` branches are created ad hoc and are not protected. The 0.16 RC tags were cut from `next` anyway.
* Tags and GitHub releases are created manually.
* The publish workflow runs its dry-run preflight with `continue-on-error`, so it does not actually gate the release.
* There are no tag rulesets, so arbitrary tag names can be pushed by anyone with permission.

I think ideally all related repos would abide by similar processes to minimize assumptions and make things easier to navigate, so maybe this should be reviewed in conjunction to other repos. In this regard, the node repo recently cleaned up the same process. See [branching-policy.md](https://github.com/0xMiden/node/blob/next/docs/internal/src/branching-policy.md), [releases.md](https://github.com/0xMiden/node/blob/next/docs/internal/src/releases.md), and [release.yml](https://github.com/0xMiden/node/blob/next/.github/workflows/release.yml).

### Some specific steps we can implement
- **Use `next` as the trunk.** `next` remains the default branch and releases are tagged from it. Create `release/vX.Y` only when a breaking change needs to land on `next` while `vX.Y` still needs maintenance. We could retire `main` at this point.
- Only run the publish dry run where it is expected to work. Run it on pushes to `release/v*` and as part of the release workflow, not on `next`.
- Mirroring the node setup and making releases tag-driven is also a possibility. I don't have a strong opinion here and think using Github's UI for creating a release with the tag (not sure why you can't create tags separately) is not bad IMO.
- Add rulesets: If we do trunk based development we need to protect `next` and `release/v*`, and add a `v*` tag ruleset that enforces the expected format and restricts who can create release tags.
- Keep version bumps separate: Ideally version bump PRs should only touch `Cargo.toml`, `Cargo.lock`, and the `CHANGELOG` heading.

Review the linked node repository's branching-policy.md, releases.md, and release.yml to understand the target process. Examine the current GitHub workflows, branch protections, and tag rules in this rust-sdk repository. The goal is to design and implement a new release process that uses `next` as trunk, creates protected release branches only when needed, and makes releases tag-driven with proper safeguards.

Written by the indexing model from the issue text.