lockfile-tamper finding text still blames 'package.json' after the check was redesigned around the lockfile's own version field

[JSONbored]

Context

src/review/lockfile-tamper.ts's header comment (lines 10-17) documents that the tamper check was redesigned (per #2676) to compare a lockfile entry's own "version" field across the diff, specifically because the old approach — treating "package.json didn't change" as a tamper signal — misfired on every ordinary transitive dependency bump. The implementation (versionChanged, scanPackageLockPatch) matches that documented design: it only parses "version" lines out of the lockfile diff itself, and never reads package.json anywhere in the file.

But the finding text rendered to users at line 227 still describes the old, abandoned behavior:

"a resolved/integrity value changed without a matching package.json version bump"

This is factually wrong given the check's own current, documented logic — there is no "package.json version bump" concept involved at all anymore. test/unit/lockfile-tamper.test.ts:59 inherited the same stale framing in its test description.

Requirements

• The finding text at src/review/lockfile-tamper.ts:227 must describe the actual check being performed (a resolved/integrity value changed without a matching version bump in the lockfile entry itself), not the abandoned package.json-comparison design.
• test/unit/lockfile-tamper.test.ts:59's description string must be updated to match, so the test doesn't perpetuate the same stale framing for future readers.
• Do not change the underlying detection logic — only the user-facing text and the test description are wrong, not the behavior.

Deliverables

• Corrected finding text in src/review/lockfile-tamper.ts:227
• Corrected test description in test/unit/lockfile-tamper.test.ts:59

Test Coverage Requirements

This repo's Codecov patch gate is 99%+ patch coverage, hard, for src/**. This is a text-only change to an already-covered code path — no new branch is introduced, so no new test is required beyond updating the existing description, but confirm the existing test suite still passes with the corrected string if any test asserts on the literal message.

Expected Outcome

The lockfile-tamper finding's user-facing text accurately describes what the check actually compares (the lockfile entry's own version field), matching the redesign documented in the file's own header comment.

Links & Resources

• src/review/lockfile-tamper.ts (header comment lines 10-17 explaining the feat(gate): add a lockfile-tamper-risk check #2676 redesign; stale text at line 227)
• test/unit/lockfile-tamper.test.ts:59

[linear-code]

JSO-4530