ci: add read-only token permissions and pin all action references to SHAs

[Alb3e3]

Summary

All seven CI workflows lacked a top-level permissions: block, so each
run inherited the repository default, which can be write-all on permissive
settings. Every workflow now has permissions: read-all at the top
level, restricting the GITHUB_TOKEN to the minimum required for build and
test jobs.

In addition, every action reference that used a mutable version tag was
pinned to its full commit SHA. A tag can be silently moved; a SHA
cannot.

Actions pinned

Action	From	To
actions/checkout	@v6	@df4cb1c (v6.0.3)
actions/checkout	@v4	@11bd719 (v4.2.2)
actions/upload-artifact	@v6	@b7c566a (v6)
msys2/setup-msys2	@v2	@e989830 (v2)
cygwin/cygwin-install-action	@master	@781ea34
vmactions/dragonflybsd-vm	@v1	@4ba8127
vmactions/freebsd-vm	@v1	@a6de934
vmactions/netbsd-vm	@v1	@99816dc
vmactions/omnios-vm	@v1	@d42d894
vmactions/openbsd-vm	@v1	@fcf799d
vmactions/solaris-vm	@v1	@d30dd6c
google/oss-fuzz/.../build_fuzzers	@master	@439b356
google/oss-fuzz/.../run_fuzzers	@master	@439b356

Verification

uvx zizmor --min-severity medium .github/workflows/

Result: 0 high-severity findings after this patch (down from 26).
The remaining 3 medium findings are style warnings about read-all being
broader than individual per-permission declarations — they are not a
regression and reflect the same posture as adding permissions: read-all
to any workflow.

[mtl1979]

Pinning to specific commit SHA is a no-go and doesn't magically fix all potential security issues in third-party actions. Most security-related bots actually prefer to pinning to major version tag instead as it will get any new security updates as soon as they are released and if the action is no longer properly maintained, it can be tagged as such.

Only Python allows setting minimum (and maximum) version for dependencies thus avoiding both breaking changes and known vulnerable or broken releases.

[Alb3e3]

@mtl1979 Sorry for the slow reply, and thank you — that is a fair objection and I am not going to argue it. Pinning does freeze known-vulnerable action versions in place unless something updates them, and without a Dependabot config in this repo to do that, the pins would just rot.

Closing this in favour of #1295, which drops the SHA pinning entirely and only adds the permissions: blocks. That part is the piece with a clear benefit and no version-management tradeoff: it restricts the default GITHUB_TOKEN from write to contents: read across the workflows, which limits what a compromised action could do regardless of how it is referenced.

#1295 touches the same seven workflow files, so the two would have conflicted anyway.