[BRE-2116] Bump actions/checkout to v7.0.1 + add bypass flag in client build workflows

[brandonbiete]

🎟️ Tracking

https://bitwarden.atlassian.net/browse/BRE-2116

📔 Objective

Bumps actions/checkout v6.0.2 -> v7.0.1 (SHA-pinned) across build-browser, build-cli, build-desktop, build-web, and chromatic (33 checkout steps), and adds allow-unsafe-pr-checkout: true to the 32 fork-content checkout steps.

These workflows run via their *-target.yml companions (pull_request_target) and check out fork head.sha to build/sign artifacts. checkout v7 refuses that fork checkout by default; without this flag the fork-PR build path is broken. The one non-fork checkout in build-web is bumped but not flagged, since v7 does not block it.

Regression-prevention only — this preserves existing behavior and does NOT remediate the underlying pwn-request exposure (fork code running in a privileged context). Remediation is scoped in the follow-up spike.

📸 Screenshots

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

This PR bumps the SHA-pinned actions/checkout from v6.0.2 to v7.0.1 across the five client build workflows (build-browser, build-cli, build-desktop, build-web, chromatic) and adds allow-unsafe-pr-checkout: true to the checkout steps that resolve github.event.pull_request.head.sha. I verified the flag coverage is exact and complete: all 32 fork-ref checkouts across those five files carry the flag (build-browser 6, build-cli 4, build-desktop 18, build-web 3, chromatic 1), and the one non-fork checkout in build-web (bitwarden/server) is correctly bumped without it. No other workflow in .github/workflows checks out a fork PR ref, so nothing else needs the flag, and no actions/checkout pin in the repo is left on v6.

Code Review Details

No findings. Notes from verification, not requiring action:

• Added lines match the indentation and ordering of the sibling persist-credentials inputs in every step.
• build-desktop.yml:96 keeps persist-credentials: true alongside the fork checkout — pre-existing (the step's git ls-remote --heads origin calls need it), unchanged by this PR, and the reusable workflow caps itself at permissions: contents: read. The privileged-context exposure is explicitly scoped out to the follow-up spike in the PR description.
• The steps are also reached by the non-privileged pull_request and push triggers, where the fork ref expression is empty; the flag is a no-op on those paths.