Align the category with the house term used in github/launch's lockfile
resolver, which frames this as an integrity check ("integrity check
failed" / "tampered" / "fails closed") and never says "forgery".
"Forgery" also over-asserted malice — the check also fires on benign
upstream history rewrites, not just injected pins.

Renames the identifier (LockfileForgery -> LockfileIntegrity), the
schema string ("lockfile-forgery" -> "lockfile-integrity"), the human
label ("Lockfile integrity"), the frozen-strings vocabulary, and the
doc-URL slug. Safe rename: no consumer anywhere in the org keys on the
old string, and the docs page is still unpublished. Also drops the stale
"SARIF rule IDs" claim from the Category doc comment — SARIF isn't a
surface this tool emits.

"Integrity" collided with github/launch's meaning: their lockfile
integrity check compares a SHA-256 digest of the runner-supplied
dependency list against a signed token claim (payload tampering in
transit). Ours is a different axis entirely — whether a single pinned
SHA is an ancestor of / reachable from the ref's current head.

"Unreachable pin" names our actual invariant, asserts no malice (the
condition also fires on legitimate upstream history rewrites), and pairs
with the existing ancestry-unknown / reachability-unknown inconclusive
categories as their definitive-negative counterpart.

The CI lint ran --no-fix WITHOUT --rescan, so it only checked structural
drift and trusted any pin already recorded in the lockfile. A stale or
unreachable pin (locked SHA no longer on the ref) sailed through CI and
only blew up at Actions runtime.

Add --rescan to the read-only lint invocations so CI re-resolves every
recorded pin against upstream and fails on unreachable-pin / ref-moved.
GH_TOKEN is already wired by actions/lint, so no new auth is needed.

The lockfile fast path trusted any ref that already had a lockfile row:
IsFullyRecorded marked the workflow Resolved, which skipped all live
resolution, reachability, and ancestry. A stale or unreachable pin whose
row existed was never re-checked — only --rescan bypassed the fast path.
So a plain `gh actions-lock` run could not catch a pin that no longer
resolves to the tag it claims.

Split recorded refs by mutability instead. Full-semver tags (v4.2.1) are
immutable — one commit for life — so a drifted SHA is always a defect;
route them through live resolution so unreachable-pin/ref-changed/
misleading-sha fire on the default path. Mutable refs (v4, v4.2,
branches) legitimately move, so they stay trusted (seeded from the
lockfile) until --rescan.

The classification is extracted into planFastPath so it can be tested
without a network resolver. SkippedRescan now counts trusted mutable
refs, which the summary surfaces.

--verify-local stays the explicit offline path: it short-circuits before
the resolver, so it still only catches structural issues (not-pinned),
not stale SHAs.

The already-pinned summary asserted "All N valid" and then, in the same
breath, told you to run --rescan "to re-verify reachability" — admitting
it had not actually verified what it just called valid. A reviewer flagged
it as confusing, and rightly so.

Now that the default run re-verifies immutable pins, that contradiction is
gone: the only refs trusted without a live check are mutable ones (v4,
main) that legitimately move. Reword the nudge to name exactly those and
say plainly they weren't live-checked, so "valid" isn't undercut. The
nudge only shows when such refs exist; an all-immutable repo just sees
"All N valid".

Update the already_pinned_all_valid scenario to assert the new copy and
exclude the old "re-verify reachability" phrasing.

The lockfile-forgery → unreachable-pin rename missed the integration
scenario catalog: dbot_forgery_blocks still asserted the old category and
golden JSON, so integration-stub/-live failed. Update the assertions and
the cosmetic descriptions to the current category name.

For a partial-semver pin (v4) with narrowing on, the summary printed two
competing messages about the same ref: the version-ref nudge said "update
the uses: line to the full version to lock precisely", while the new
mutable-ref line said "run --rescan to re-verify". A reviewer rightly asked
which one to follow.

They're not equals. Narrowing v4 → v4.2.1 is the real fix: it locks
precisely AND makes the ref immutable, so the default run re-verifies it
live from then on. So when narrowing is on, the version-ref nudge is the
single actionable message; the --rescan line only muddies it.

Gate the mutable-ref nudge on --no-narrow, where the version-ref nudge is
suppressed and the trust gap would otherwise go unmentioned. Branch pins
(main), which never get a version-ref nudge, keep their honest signal
there. Update the already_pinned_all_valid scenario accordingly.

The three existing verify_local_* scenarios only exercise functionality;
they inherit ambient GH_TOKEN / gh auth via Open3.capture3 and never block
the network, so a regression where --verify-local started resolving over
the network would still pass on any authed runner. The no-network
guarantee rested entirely on code structure (the run.go short-circuit
before resolver setup), with no test pinning it.

Add a declarative env override to the scenario catalog (nil unsets a var)
and a verify_local_offline_unauthed scenario that strips all tokens and
points GH_HOST at a refused address (127.0.0.1:1). Any network call or auth
lookup fails closed under that trap, so the scenario only passes while the
offline path is truly offline. Harden the harness repro/PTY paths against
nil env values so unset vars render as `unset K` instead of crashing.