ci: scope workflow permissions to what each job uses

[arpitjain099]

Follow-up to #1981, where @bartlomieju pointed out that release.yml was the wrong target and that the top-level write-all on the other workflows is the actual exposure.

ci.yml and update-v8.yml both set permissions: write-all. Across the whole repository three steps need a write-scoped GITHUB_TOKEN, all of them softprops/action-gh-release gated on startsWith(github.ref, 'refs/tags/'). This sets contents: read at the top of both workflows and grants contents: write on the three jobs that hold those steps.

One correction to what I wrote on #1981: I said the release steps were in build and build-asan. They are in build, build-windows-arm64 and build-windows-arm64-simdutf. build-asan has no release step and gets no elevation here.

What I checked for everything else that touches a token:

• update-v8.yml performs every write through DENOBOT_PAT, including the git remote set-url and the GITHUB_TOKEN it passes to auto_update_v8.ts. The workflow token is used only by actions/checkout, so contents: read is sufficient and write-all was buying nothing, the same point you made about release.yml.
• The publish job authenticates to crates.io with CARGO_REGISTRY_TOKEN, and its actions/download-artifact reads artifacts from its own run, which needs no added scope.
• actions/cache authenticates to the cache service with the runner's own token rather than GITHUB_TOKEN, so restore and save are unaffected by narrowing the workflow token.
• release.yml is untouched, since it has no permissions block and, as you said, its authority comes from the PAT either way.

Worth being explicit about what this does and does not buy, since that was the flaw in my last PR. For pull requests from forks GitHub already issues a read-only token no matter what this key says, so this changes nothing for outside contributions. It applies to push and tag runs on the repository itself, where a compromised action currently inherits full write. That is the case the SHA-pinning PR is aimed at, and I will send that separately.

No behavioural change is expected. If a job does turn out to need a scope I have missed, the failure is a clear 403 from the API rather than anything silent.