ci: standardize actions/checkout to v5 across all workflows

[Devansh-567]

Summary

This repo's GitHub Actions workflows pinned actions/checkout to several different major versions inconsistently:

• @v3 - any-branch-uploads.yml, main-branch-uploads.yml, tag-uploads.yml (x2), codegen.yml, spec.yml (asciidoc-lint, build-spec jobs)
• @v4 - bazel-build.yml
• @v5 - rust-build.yml, google-rpc-status-synced.yml
• @v6 - spec.yml (verify-licenses job)

This PR standardizes all actions/checkout references to a single version: @v5.

Why v5

• Already in use and working in this repo (rust-build.yml, google-rpc-status-synced.yml), so it's a proven baseline rather than an untested jump.
• Recent and actively supported, without being the very newly released v7 (GA'd June 17, 2026), which introduces new default behavior for pull_request_target/workflow_run checkouts. None of this repo's workflows use those triggers, so it wouldn't have caused issues either way, but v5 avoids being an early adopter of a days-old major version in CI.

Changes

Purely mechanical version bumps, no other changes:

• any-branch-uploads.yml: v3 -> v5
• bazel-build.yml: v4 -> v5
• codegen.yml: v3 -> v5
• main-branch-uploads.yml: v3 -> v5
• spec.yml: v6 -> v5 (verify-licenses), v3 -> v5 (asciidoc-lint), v3 -> v5 (build-spec)
• tag-uploads.yml: v3 -> v5 (x2)

rust-build.yml and google-rpc-status-synced.yml are unchanged as they already used v5.

[matthewtlam]

Could you explain why you are downgrading this from v6 --> v5? Are there any downgrade implications? I assume it's just for consistency

[Devansh-567]

Could you explain why you are downgrading this from v6 --> v5? Are there any downgrade implications? I assume it's just for consistency

Yes 😊, this is purely for consistency, not because v6 has a known issue.
On downgrade implications: I checked the actions/checkout release notes between v5 and v6, and there's no breaking change or behavior difference relevant to this workflow's verify-licenses job (it's a straightforward checkout, no special inputs like persist-credentials, sparse-checkout, or ref handling that changed between versions). So functionally this job will behave identically on v5.
The reasoning for picking v5 as the repo-wide standard rather than bumping everything to v6 (or v7):

v5 is already proven in this repo (rust-build.yml, google-rpc-status-synced.yml use it today), so standardizing on it means every workflow converges on a version that's already known to work here, rather than introducing a new version through this PR.
v6/v7 aren't broken or risky, but since none of the workflows need anything from those newer releases, there was no upside to bumping up to v6 across the board versus consolidating down to the version already validated in-repo.