ci: pin workflow dependencies to immutable refs

[sweidinger]

What and why

Every third-party reference in .github/workflows resolved through a mutable pointer: @v7 on the actions, @latest on the ThreatCrush install, and a bare git+https://… for vu1nz that installs whatever HEAD is at the moment the job runs. A tag is a ref its owner can repoint at any commit, so all three mean these workflows can execute code nobody here reviewed, with no diff to show for it. That matters most on the two security workflows, which run with ANTHROPIC_API_KEY and a repo token in scope — the job that is supposed to catch a supply-chain problem was itself the softest way in.

Each reference now names a commit, with the human-readable version in a trailing comment so Dependabot rewrites both halves together. The pins are not an endorsement of the pinned code — they only guarantee a change upstream arrives as a visible diff rather than a silent swap.

Reference	Pinned to
actions/checkout	3d3c42e5… (v7)
actions/setup-node	82076278… (v7)
actions/setup-python	a26af69b… (v5)
actions/upload-artifact	ea165f8d… (v4)
actions/github-script	f28e40c7… (v7)
github/codeql-action	f3712979… (v3)
@profullstack/threatcrush	0.11.2
vu1nz-gh-actions	a6055f69…

Each of the six action SHAs was checked against the major tag its comment claims, by dereferencing refs/tags/<v> upstream. ThreatCrush pins to 0.11.2, currently also its latest; the existing --format probe stays and now guards a bad bump instead of a surprise release.

Two things that are not pure mechanism, called out so they are not missed in the diff:

• checkout moves v4 → v7 in vu1nz-scan.yml, to match ci.yml and threatcrush-scan.yml. That step passes no inputs, so the bump is the version number and nothing else.
• vu1nz-scan.yml loses its sh1pt fleet header, the same way threatcrush-scan.yml already had. The file is no longer byte-identical to the pack, so the pack's content hash no longer describes it, and a stale hash that nothing verifies is worse than no hash at all.

coinpay.yml has the same unpinned-action problem but raises a separate question — whether the workflow should exist at all — so it is split out into its own PR rather than decided here. This PR is independent of it and can merge on its own.

Checklist

• npm run typecheck is clean
• npm test passes (45 files, 311 tests)
• New logic has a test (vitest; mock node built-ins for platform code) — n/a, no source change
• If I added a key, I updated both HELP_GROUPS and footerHints in src/ui/keymap.ts — n/a
• If I added a Store field, I updated makeStore in scripts/render-previews-impl.tsx — n/a
• OS-touching code works on Windows, macOS, and Linux — n/a, CI config only
• One concern, with a Conventional Commits title