ci: publish to npm via trusted publishing

[ssalbdivad]

Switches the `release` job from the `NPM_TOKEN` secret to npm trusted publishing (OIDC). Trusted publishers for all 18 published names are already configured on npm against `publish.yml`.

• `release` job: `id-token: write` + `contents: write`
• updates npm to `^11.5.1` before publishing (pnpm 10 delegates to `npm publish`)
• drops `NPM_TOKEN`/`NODE_AUTH_TOKEN` from the publish step
• adds `repository` to `arkregex` and `@ark/util` (npm checks it against the repo for provenance)

After the first successful release, revoke the `NPM_TOKEN` secret/token and optionally set each package to disallow token publishing.

[pullfrog]

✅ No new issues found.

Reviewed changes

• Release job OIDC permissions — adds job-level permissions: contents: write + id-token: write to the release job so publish can mint GitHub OIDC tokens while retaining tag-push/release privileges, and drops the NPM_TOKEN/NODE_AUTH_TOKEN env that NPM_TOKEN-based auth relied on.
• npm upgrade step — installs npm@^11.5.1 globally before pnpm ci:publish; with pnpm@10.19.0 pinned, pnpm publish shells out to the npm CLI, and trusted publishing requires npm ≥11.5.1.
• Package metadata — adds repository (url + directory) to arkregex (ark/regex) and @ark/util (ark/util), completing npm's requirement that every published package's repository.url match the GitHub repo. Both additions match the existing convention in ark/type, ark/schema, etc.

Verified against the npm trusted-publishing docs: id-token: write is the load-bearing permission, and npm 11.5.1+ exchanges the OIDC token before any token fallback, so actions/setup-node's registry-url .npmrc does not interfere.

ℹ️ The Update npm step is only load-bearing while pnpm stays on 10.x

The comment at .github/workflows/publish.yml:66 ("pnpm publish delegates to npm") is accurate for the pinned pnpm@10.19.0 (package.json:113), but pnpm 11 replaced delegation with a native publish flow — at which point npm install -g npm@^11.5.1 becomes a no-op and OIDC handling shifts entirely to pnpm's own implementation. Nothing here is wrong today, but a future pnpm major bump would need to re-validate this path.

Technical details

# pnpm publish ↔ npm CLI delegation is version-bound

## Affected sites
- `.github/workflows/publish.yml:66` — the explanatory comment presents delegation as a permanent fact rather than a property of the pinned pnpm major.
- `.github/workflows/publish.yml:67-68` — `npm install -g npm@^11.5.1` only affects publish auth while pnpm 10.x delegates to the `npm` on `PATH`.
- `package.json:113` — `"packageManager": "pnpm@10.19.0"` is what currently keeps delegation in effect; `engines.pnpm` only requires `>=10`.

## Required outcome
- No change required for this PR. If pnpm is later upgraded to 11+, re-verify the release job (pnpm native publish + OIDC) instead of assuming the npm upgrade still governs publishing.

## Suggested approach (optional)
- Tie the comment to the pin, or make the mechanism version-proof by switching `ark/repo/publish.ts` to `pnpm pack && npm publish <tgz>`.

## Open questions for the human (optional)
- Is a pnpm 11 upgrade planned? That determines whether the npm-upgrade step is worth keeping long term.

  ^{｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}