[Desolate-Jix]

Catalog admission currently fails before inspecting any package from a fork: actions/checkout@v7 rejects the proposal checkout in the pull_request_target job. This was reproduced by submission #7, failed checkout job.

Enable the documented allow-unsafe-pr-checkout input only for the proposal checkout, with an explicit data-only boundary. Keep contents: read, persist-credentials: false on every checkout, the protected-base checker/hashed requirements, and the fixed Host SHA unchanged. No proposal script, requirement file or submitted wheel is installed or executed by the trusted admission job. The existing generator path still requires source/generator commits to be ancestors of the protected base and executes the approved generator from a trusted clone.

Add an actual CLI regression using the pinned Host: a proposal containing impostor catalog.py, sitecustomize.py, tools/check_catalog_ci.py and an invalid requirement file is accepted as an unchanged catalog without executing any Python sentinel. It checks process exit, exact output and absence of the marker. This is CLI/import-boundary coverage; workflow dependency provenance was reviewed separately, and existing catalog tests cover artifact/generator behavior. Ordinary unprivileged PR test jobs continue running their tests as before.

Validation on Windows / CPython 3.12.10:

• Complete offline suite: 151 passed, 16 skipped (the default run has no explicit pinned-Host environment).
• Real pinned-Host CLI sentinel regression: 1 passed.
• Full pinned-Host catalog suites: 39 passed, including the new CLI/import-boundary case.
• SDK wheel build and whitespace checks passed. Independent read-only trust-boundary review found no blocker. Groups overlap; do not add them as unique tests.

Checkout v7 behavior and opt-in.

This PR is separate from the extension submission and changes no catalog entry, approval or release artifact. The protected admission check on this PR still uses the current base workflow; this repair takes effect after a maintainer merges it into main. Then trigger a fresh PR event on #7 so the updated base workflow is selected; rerunning the original failed run can retain its old workflow revision.