actions/unpinned-tag should recognize GitHub actions.lock enforcement

[hyperpolymath]

Problem

The actions/unpinned-tag query reports a GitHub Actions dependency as mutable
even when GitHub's actions.lock enforcement resolves and executes it at an
immutable commit.

This causes the CodeQL pull-request check to fail on new workflow lines that are
covered by a valid lockfile.

Reproduction

Public example: metadatastician/enaction-engine, PR #53, commit
692196676436c6cf87949925bc4b900085e288b5.

CodeQL 2.26.4 reports two medium-severity alerts at
.github/workflows/rust-ci.yml lines 29 and 62:

Unpinned 3rd party Action 'Rust CI' step uses
'dtolnay/rust-toolchain' with ref 'v1', not a pinned commit hash

The source is:

- uses: dtolnay/rust-toolchain@v1

The repository's .github/workflows/actions.lock binds that exact reference:

'dtolnay/rust-toolchain@v1':
    ref: 'v1'
    commit: 'sha1-6c977a6ca4077a0ceb28ffbe03f59d46e9ac8772'
    owner_id: 1940490
    repo_id: 260749683

The repository has GitHub's sha_pinning_required Actions setting enabled, and
the workflow executes the locked commit. The official
github/gh-actions-lock extension v0.1.6 verifies all 27 workflows:

$ gh actions-lock --verify --json=valid,findings
{"valid":true,"findings":[]}

A deliberately introduced unlocked action reference is detected by the same
verifier, providing a positive control.

Security distinction

The lockfile binds the direct immutable commit plus the GitHub owner/repository
numeric identities and immutable transitive dependencies of composite actions.
Replacing the symbolic source reference with an inline SHA expresses only the
direct commit and can make an Actions-lock-enforced workflow fail admission.

Requested behavior

Please make actions/unpinned-tag lockfile-aware. A symbolic uses: reference
should not be reported as unpinned when the exact reference and workflow edge
are covered by a valid .github/workflows/actions.lock entry with a full commit
and repository identity.

If the query cannot establish lockfile integrity, consider a distinct
"externally lock-enforced" classification rather than asserting that the
dependency executes from the mutable tag.

Related local evidence and owner ruling:
hyperpolymath/standards#674