ci: integration tests fail at checkout on all fork PRs (actions/checkout allow-unsafe-pr-checkout default) #709

Integration tests fail at checkout for every PR opened from a fork. No integration test runs, so a red Test (...) check on a fork PR currently says nothing about the code.

What happens

All 10 matrix jobs in .github/workflows/integration-testing.yml fail at the Checkout PR head commit step in under 10 seconds:

##[error]Refusing to check out fork pull request code from a 'pull_request_target' workflow.
This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache scope,
and runner access. Fetching and executing a fork's code in that trusted context commonly leads to
"pwn request" vulnerabilities. To opt in, review the risks at
https://gh.io/securely-using-pull_request_target and set 'allow-unsafe-pr-checkout: true' on the
actions/checkout step.

Set up Python, Install dependencies and Run integration tests are then skipped.

Examples: #706 (leewc/...), and fix/memory-session-manager-boto-session (avneetbansal-aws/...). PRs whose branch lives in this repo are unaffected.

Cause

actions/checkout v6.1.0 (and v5.1.0) backported a breaking default, allow-unsafe-pr-checkout: false, that refuses to check out fork code under pull_request_target. The workflow uses the floating actions/checkout@v6 tag, so it picked this up without a change here. Changelog: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/

The repo's own trust gate isn't the blocker. On #706, authorization-check passed because the author has write access, and checkout still refused.

Options

1. Set allow-unsafe-pr-checkout: true on the Checkout PR head commit step only. The workflow already has the mitigations the changelog describes: authorization-check requires write permission, other authors go through the manual-approval environment, the safety check blocks PRs touching .github/workflows/, .github/actions/, conftest.py and pytest.ini, and persist-credentials: false is set. This is a maintainer call since it opts back into the risk the new default exists to prevent.
2. Ask contributors with write access to push branches to this repo instead of a fork. No workflow change, but external contributors still get no integration coverage.

Pinning to @v5 won't help, because v5.1.0 carries the same default. Pinning to a pre-v6.1.0 SHA would work but silently drops a security fix, so I'd avoid it.