Add a shared melos versioning workflow beside publish.yml

## Problem

This repo shares `ci.yml`, `pr-title-check.yml`, and `publish.yml` — everything around a release except **producing** the release. Each consumer writes its own versioning workflow, and they are converging on the same implementation independently.

`btwld/mix` (`.github/workflows/changelog.yml`):

```bash
melos version $ignored_packages --yes --no-git-tag-version $packages_with_versions
git push --follow-tags
gh pr create --title "chore: version packages" --reviewer leoafarias
```

`conceptadev/remix` (`.github/workflows/version.yml`, just added in [remix#148](https://github.com/conceptadev/remix/pull/148)):

```bash
melos version --prerelease --preid beta --no-git-tag-version --yes $overrides
git push --set-upstream origin "$branch" --force
gh pr create --title "chore(release): version packages" --base main --head "$branch"
```

Same tool, same flags, same shape — two copies. Remix arrived at it by porting mix's after release-please proved unusable for Dart prereleases ([googleapis/release-please#2400](https://github.com/googleapis/release-please/issues/2400)).

## Why it belongs here

The non-obvious parts are already shared knowledge rather than per-repo preference, and each one was learned the hard way:

- **`--no-git-tag-version` is mandatory.** `publish.yml` in this repo fires on a tag push, so a versioning step that tags would publish before the version PR is reviewed. Both consumers independently discovered this and both comment it.
- **`gh pr create` instead of letting the action open the PR.** Sidesteps *Allow GitHub Actions to create and approve pull requests*, which is off in at least one consumer org and blocks release-please entirely.
- **`fetch-depth: 0` is required.** melos derives a package's last release from its `-v*` tag; a shallow clone makes it walk all history and rewrite the entire changelog. Remix hit exactly this — a 63-line changelog reaching back a year, until an anchor tag was added.
- **Tag convention is `-v`.** Consumers that used a bare `v` silently get the wrong changelog range rather than an error.

That is four sharp edges, none of which is discoverable without a failed release.

## Suggested shape

A `version.yml` reusable workflow taking roughly:

```yaml
with:
packages: | # for -V overrides and the PR body
remix
remix_fortal
prerelease: true # --prerelease
preid: beta # --preid
graduate: false # --graduate, mutually exclusive with prerelease
base_branch: main
branch: release/version-packages
```

and always applying `--no-git-tag-version`, `fetch-depth: 0`, and `gh pr create`.

Consumers keep what is genuinely theirs: which packages exist, whether they are on a prerelease line, and the tag push itself.

## Prior art to copy from

- `btwld/mix` — `.github/workflows/changelog.yml`, stable versioning with per-package version overrides
- `conceptadev/remix` — `.github/workflows/version.yml`, prerelease line with `--preid beta` and a `graduate` toggle

Remix's is the newer of the two and covers the prerelease case mix does not, so it is probably the better starting point. Happy to open the PR here if this is wanted.

Start by reading conceptadev/remix's .github/workflows/version.yml, then compare it with btwld/mix's .github/workflows/changelog.yml and this repository's publish.yml. The reusable workflow should expose the listed package and release inputs while always using --no-git-tag-version, fetch-depth: 0, the package-v tag convention, and gh pr create. Done means the shared versioning workflow covers both stable and prerelease or graduate cases without triggering publish before review.

Written by the indexing model from the issue text.