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.

Überprüfen Sie die verknüpfte node-Repository-Datei branching-policy.md, releases.md und release.yml, um den Zielprozess zu verstehen. Untersuchen Sie die aktuellen GitHub-Workflows, Branch-Schutzregeln und Tag-Regeln in diesem rust-sdk-Repository. Das Ziel ist es, einen neuen Release-Prozess zu entwerfen und zu implementieren, der `next` als Trunk verwendet, geschützte Release-Branches nur bei Bedarf erstellt und Releases tag-gesteuert mit angemessenen Sicherheitsvorkehrungen durchführt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.