fix: use the invoked trusted workflow revision

[danbarr]

Summary

• check out the trusted scanner implementation from github.workflow_sha
• avoid binding approvals to a stale pull request merge base
• document the workflow revision trust anchor

Context

The final trusted scan for #925 ran after #992 merged, but github.event.pull_request.base.sha still pointed to 29ccd7d, the pull request branchs older merge base. The trusted scan therefore recorded approval hashes for the old workflow implementation. When the merge commit reached main, the build correctly rejected every approval with trusted scan implementation changed after approval and fell back to fresh LLM scans. Two fresh verdicts then blocked publication in run 35362527423.

github.workflow_sha identifies the exact trusted commit from which GitHub loaded the pull_request_target workflow. Checking out that revision keeps the executed workflow and its scanner implementation aligned even when the pull request branch is behind main.

Validation

• actionlint on all four skill workflow files, excluding existing ShellCheck diagnostics
• zizmor with no unsuppressed findings
• git diff --check

Because pull_request_target uses the default-branch workflow definition, this checkout behavior must be confirmed on a skill-changing pull request after merge.