feat: add commit SHA check to skip redundant scans

[sgerlach]

Summary

• Adds opt-in commitShaCheck input that looks up existing StackHawk scan results by commit SHA before running a new scan
• When a matching scan is found, posts results as a PR comment and GitHub Step Summary, then passes/fails based on the scan's threshold status — skipping the CLI scan entirely
• When no matching scan is found, falls through to run HawkScan normally
• Automatically derives organizationId from the application lookup (GET /api/v1/app/{appId}) — no extra config needed
• Gracefully degrades to normal scan on any API error

New Action Input

Input	Required	Default	Description
commitShaCheck	no	false	Enable SHA lookup against StackHawk platform before scanning

Example Usage

- uses: stackhawk/hawkscan-action@v2
  with:
    apiKey: ${{ secrets.HAWK_API_KEY }}
    commitShaCheck: 'true'
    configurationFiles: stackhawk.yml
    codeScanningAlerts: true
    githubToken: ${{ github.token }}

The configurationFiles is always required — the action parses applicationId from it for the SHA lookup. If no existing scan is found, the action falls through to a normal HawkScan run using the same config.

New Modules

• src/config_parser.js — Parses applicationId from stackhawk.yml
• src/scan_check.js — StackHawk API auth, app lookup for orgId, scan search by GIT_SHA tag
• src/scan_summary.js — Markdown formatting for PR comment and Step Summary

Test plan

• Verify npm run all passes (lint + build + test) — 36 tests across 4 suites
• Test with commitShaCheck: false (default) — should behave identically to current action
• Test with commitShaCheck: true and a commit that has an existing scan — should find scan, post summary, skip CLI run
• Test with commitShaCheck: true and a commit with no existing scan — should fall through to normal scan
• Test API auth failure graceful degradation — should warn and fall through to normal scan
• Test app lookup failure graceful degradation — should warn and fall through to normal scan

[Bwvolleyball]

organizationId as a required input

Do we need organizationId as a separate user-provided input? Since the action already has the apiKey and parses applicationId from stackhawk.yml, the org should be derivable — apps can only belong to one organization.

The auth response from /api/v1/auth/login likely contains the org ID, or we can look it up from the app. That would let us drop the organizationId input entirely and reduce setup friction for users.