lockfile-tamper.ts module header claims broader lockfile support than isNpmLockfilePath actually provides

[JSONbored]

Context

src/review/lockfile-tamper.ts's module-level doc comment (lines 1-7) describes the check as scanning "a changed package-lock.json (or another *.lock file) diff" — but isNpmLockfilePath (lines 50-59), the function that actually decides what gets scanned, has its own accurate doc comment stating it's "the only lockfile format this check parses today (npm/lockfileVersion 2-3 JSON shape)" and its implementation only matches basename === "package-lock.json". yarn.lock, pnpm-lock.yaml, and any other *.lock file are silently never scanned. The module header is stale/misleading relative to the function's own correct, more specific doc comment and actual behavior.

Requirements

• Correct the module-level doc comment (lines 1-7) to state the check scans package-lock.json specifically (npm only), not "another *.lock file" generically — align it with isNpmLockfilePath's own accurate doc comment.
• This issue is scoped to the doc-comment correction only. Do not extend isNpmLockfilePath to parse yarn/pnpm lockfiles — that's a materially different parsing format and a separate feature scope, not a doc-accuracy fix. A PR that adds yarn/pnpm parsing does not satisfy this issue.

Deliverables

• Module-level doc comment in src/review/lockfile-tamper.ts accurately describes npm-only scope

Test Coverage Requirements

Doc-only change — no behavioral diff, so no new test is required. If the PR review flags a coverage gap anyway, a no-op assertion that isNpmLockfilePath still rejects a yarn.lock path is acceptable.

Expected Outcome

The module's own header comment matches what the code actually does and what its own function-level doc comment already correctly states — no more contradictory documentation within the same file.

Links & Resources

src/review/lockfile-tamper.ts:1-7 (module header, to fix), :50-59 (isNpmLockfilePath, the accurate reference).

[linear-code]

JSO-4760