fix: serialize multi-semantic-release init to avoid flaky release failures

[ffflorian]

Problem

The Release on npm step failed on run 30022960959 with ENONPMTOKEN No npm token specified for electron-info and @ffflorian/jszip-cli.

The root cause is not a missing token or a code regression:

• Every prior release run was green; this is the first failure, and the only release-tooling dependency change since then was top-level semantic-release 25.0.6 -> 25.0.8, which multi-semantic-release does not use (it bundles its own nested copy).
• All packages are correctly configured for npm OIDC trusted publishing.
• The two attempts of the same commit failed with different errors:
  • Attempt 1: git log ... --notes=refs/notes/semantic-release* exited 128 (Failed to read notes tree).
  • Attempt 2: ENONPMTOKEN for a subset of packages (their OIDC token exchange returned nothing).

Non-deterministic failures across re-runs point to a concurrency/throttling issue. multi-semantic-release runs every package's init/verifyConditions phase in parallel with no concurrency limit, so all ~15 packages fire their git tag/notes reads and npm OIDC token exchanges simultaneously. Under that burst the calls intermittently collide or get rate limited, and which packages fall over varies run to run.

Changes

• release script: add --sequential-init. This is the built-in multi-semantic-release flag for exactly this case (its own comment: "Avoid hypothetical concurrent initialization collisions / throttling issues", Is it possible to add the --debug arg to be passed to semantic-release? dhoulb/multi-semantic-release#24). It serializes the init phase so each package initializes one at a time, so the git-notes reads and OIDC token exchanges no longer race or get throttled.
• Workflow: grant issues: write to the release job. When a release does fail, @semantic-release/github's fail step tries to open a "release is failing" issue and was getting 403 Resource not accessible by integration because the job only had id-token + contents. This lets that notification be created instead of erroring.

Verification

The release step only runs on push to main (skipped on PRs), so the real confirmation is the next push to main, or re-running the failed job with these changes in place.