[ci] Bug Fix: grant id-token: write in version.yml release call

[etrepum]

Description

The "Create New Release Branch" workflow (version.yml) failed GitHub's workflow validation with:

The nested job 'publish' is requesting 'id-token: write', but is only
allowed 'id-token: none'.

version.yml calls the reusable workflow call-release.yml, whose publish job declares id-token: write for npm trusted publishing (OIDC). GitHub validates a reusable workflow's permission requests against the caller statically — regardless of if: conditions — so even though version.yml never sets publish: true, the caller must still grant every permission the nested jobs declare. version.yml only granted contents: write.

This adds id-token: write to version.yml's permissions block, matching the sibling caller pre-release.yml.

Test plan

Before

version.yml rejected by GitHub as an invalid workflow file (see error above); the workflow could not be dispatched.

After

version.yml passes workflow validation and can be dispatched; the publish job's id-token: write request is now satisfied by the caller.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
lexical	Ready	Preview	Jun 25, 2026 5:32pm
lexical-playground	Ready	Preview	Jun 25, 2026 5:32pm

[potatowagon]

Reviewed by Navi (Tater Thoughts Bobblehead) on behalf of @potatowagon.

LGTM ✅

Summary: This PR adds id-token: write to version.yml's top-level permissions block so that the reusable call-release.yml workflow (whose publish job declares id-token: write for npm OIDC trusted publishing) can pass GitHub's static permission validation.

What I checked:

1. Correctness: GitHub validates reusable workflow permission requests statically against the caller — even for jobs gated by if: conditions that will never run. The fix correctly mirrors what pre-release.yml already does (as the PR description notes), making this a straightforward alignment.
2. Security: id-token: write is scoped to OIDC token issuance for the workflow run — it doesn't grant write access to repo contents, packages, or other sensitive scopes. The permission is already present in the sibling pre-release.yml caller, so this doesn't expand the overall attack surface.
3. Edge cases: Since version.yml never sets publish: true, the publish job won't actually execute, but GitHub still requires the permission grant statically. No behavioral change.
4. CI status: All checks pass — core-tests (unit, browser, integrity), e2e-tests (chromium), CLA, Vercel deploys. The browser/e2e/integration tests show "skipping" from the workflow-level check_should_run gate (CI-only change, no code paths affected).
5. www compat: N/A — this is a CI workflow change with no code/API impact.

Verdict: Safe to merge. Single-line permissions addition that unblocks the release workflow. No risk of regression.