What breaks. checkout v7.0.0's headline breaking change (actions/checkout#2454) adds a guard, assertSafePrCheckout(), that refuses to check out fork-PR head code from a pull_request_target- or workflow_run-triggered workflow unless the new allow-unsafe-pr-checkout input is explicitly set to true (it defaults to false). This PR bumps the docs-preview build job's checkout to v7 without setting that input, and this job is exactly the case the guard targets: it runs on pull_request_target and checks out ref: ${{ needs.authorize.outputs.head_sha }}, which the authorize job sets verbatim from context.payload.pull_request.head.sha.

The exact code path (verified against the pinned SHA 9c091bb, tag v7.0.0):

1. src/input-helper.ts (lines 75–77) reclassifies a 40-hex ref input as result.commit with result.ref = ''.
2. src/input-helper.ts (lines 166–176) reads allow-unsafe-pr-checkout (default false) and calls assertSafePrCheckout() unconditionally during input parsing — before any fetch.
3. src/unsafe-pr-checkout-helper.ts throws "Refusing to check out fork pull request code from a pull_request_target workflow..." when all three hold: eventName === 'pull_request_target', pull_request.head.repo.id !== repository.id (any fork PR), and the resolved commit matches pull_request.head.sha (the prShas list also includes merge_commit_sha).

Step-by-step proof. A repository admin opens (or pushes to) a fork PR touching docs/**, docs_src/**, mkdocs.yml, scripts/docs/**, or pyproject.toml:

1. docs-preview.yml triggers on pull_request_target; authorize outputs head_sha = context.payload.pull_request.head.sha and authorized = true (admin sender).
2. build runs actions/checkout@v7 with ref: <head_sha> → reclassified as commit.
3. Guard evaluation: event is pull_request_target ✓; head repo id ≠ base repo id (fork) ✓; input.commit === pull_request.head.sha ✓ (it was passed through verbatim). All conditions met → the checkout step throws.
4. build fails; comment runs (always() + authorized) with DEPLOY_RESULT != 'success' and posts "❌ Preview build failed" on the PR. Before this bump (v6.0.3) the same run built fine.

Why nothing else prevents it. The workflow already implements precisely the mitigations the v7 guard exists to enforce — admin-gated authorize job, build isolated from all secrets, static site handed to deploy via artifact, enable-cache: false — but the guard cannot see any of that; it keys only on event name + fork head-repo id + commit==head sha, all of which match here. Note also that this dependabot PR's own CI stays green: it's a same-repo PR, so the guard returns early on headRepoId === baseRepoId. The breakage is silent until the next fork-PR docs change. The /preview-docs slash-command path is unaffected (issue_comment returns early from the guard), so a manual workaround exists, but the auto-preview path is the workflow's documented primary flow.

Scope of the rest of the PR. All other bumped checkout call sites run under push/pull_request/release/issue_comment/workflow_call triggers, none of which the guard inspects — they're fine. The other three bumps are also benign: all pinned SHAs match their claimed tags (github-script v9.0.0 = 3a2844b, zizmor-action v0.5.7 = 192e21d, claude-code-action v1.0.159 = a92e7c7), and github-script v9's breaking changes (removal of require('@actions/github'), injected getOctokit) don't intersect with the inline scripts in docs-preview.yml.

Fix. Add allow-unsafe-pr-checkout: true to the build job's checkout step in docs-preview.yml (likely with a zizmor ignore comment mirroring the existing dangerous-triggers ignore), or hold this one checkout at v6. One line either way.