ci: add npm release workflow

[V3RON]

What is this?

This PR adds a manual npm release workflow and configures Changesets so Voltra publishes with a single shared package version. It replaces the current implicit/manual release path with a dispatchable GitHub Actions flow that can version packages, publish to npm via trusted publishing, tag the release, and create a GitHub Release.

How does it work?

Changesets now treats all public Voltra packages as one fixed release group, so a release resolves to one version across the package set. The new Release workflow runs only by workflow_dispatch, validates that it is running from main, installs without pnpm caching, verifies the release plan has exactly one version, runs package validation, versions packages, commits chore: release X.Y.Z, publishes with pnpm run release -- --no-git-tag, creates a unified vX.Y.Z tag, and creates the GitHub Release from that tag. The workflow grants no default permissions and scopes the job to contents: write plus id-token: write for GitHub writes and npm trusted publishing.

Why is this useful?

This makes releases repeatable without storing an npm token in GitHub secrets. The fixed Changesets group prevents split package versions, while the workflow keeps release commits, npm publishing, tags, and GitHub Releases aligned around one version. The explicit branch check, disabled package-manager cache, no persisted checkout credentials, and narrow token permissions reduce the operational risk around publishing.

[yassinetou9]

Duplicate version verification logic

The Node script that validates exactly one release version is duplicated in both the "Check release plan" step (lines 50–65) and the "Resolve release version" step (lines 75–95). This repeated code is a maintenance burden and increases cognitive load during review.

Suggested fix: Extract this logic into a separate script file (e.g., .scripts/validate-release-version.js) and call it from both steps:

// .scripts/validate-release-version.js
const plan = require('./.changeset-release-plan.json');

const versions = [...new Set(
  plan.releases
    .filter((release) => release.type !== 'none')
    .map((release) => release.newVersion)
    .filter(Boolean)
)];

if (versions.length === 0) {
  throw new Error('No packages to release');
}

if (versions.length !== 1) {File: `.github/workflows/release.yml`  
Lines: 50–65 and 75–95

````markdown
### Duplicate version verification logic

The Node script that validates exactly one version is copy-pasted in two places: in the "Check release plan" step and again in the "Resolve release version" step. Both blocks do the same thing — parse `.changeset-release-plan.json`, filter releases, extract unique versions, and validate that exactly one version exists.

Consider extracting this into a reusable shell function or a separate Node script file (e.g., `.github/scripts/get-release-version.js`) so there's a single source of truth. This will:
- Make the workflow more readable
- Reduce the chance of the two copies drifting apart
- Make future updates easier and less error-prone

Example refactor:
```bash
# .github/scripts/get-release-version.js
const plan = require('../.changeset-release-plan.json')
const versions = [...new Set(
  throw new Error(`Expected one release version, got: ${versions.join(', ')}`);
}

console.log(versions[0]);

Then in the workflow, replace both inline scripts with:

# In "Check release plan" step:
- run: node .scripts/validate-release-version.js > /dev/null

# In "Resolve release version" step:
- run: echo "RELEASE_VERSION=$(node .scripts/validate-release-version.js)" >> "$GITHUB_ENV"

This keeps the logic in one place, makes the workflow easier to read, and simplifies testing.

[yassinetou9]

@V3RON Thanks for the PR — small suggestion: preinstall the Android NDK (and remove any partial/corrupt NDK folders) in the native-kotlin-test job and run sdkmanager with a few retries. This prevents intermittent Gradle failures like "Error on ZipFile unknown archive" when the runner tries to download the NDK during the build.