v0.4.23: please validate portable report IDs on real runners

[CAOShurong]

VulnFuse v0.4.23
removes checkout-, runner-, drive-, and user-specific prefixes from the source
report labels generated by the CLI and GitHub Action.

Why this release exists: v0.4.22 used the absolute file returned by glob
expansion as both exported source evidence and part of finding identity.
Byte-identical OpenVEX input at the same relative path under two checkout roots
therefore changed every source finding ID, cluster ID, SARIF fingerprint, and
the output bytes. It also persisted the local path.

What was verified before publishing:

• Node 22/24, Windows CLI, bundled Linux Action, clean package, Pages, and
  CodeQL workflows passed on the merge commit.
• The downloaded v0.4.23 CLI and Action each produced byte-identical SARIF from
  identical inputs under two checkout roots, with the label
  reports/openvex.json.
• Downloaded CLI and Action malformed-input paths exited 1 without writing the
  requested output.
• Microsoft SARIF Multitool 5.6.0 reported zero validation findings for the
  exercised OpenVEX/CycloneDX outputs.
• All six release assets matched the anonymous GitHub API sizes and SHA-256
  digests, the five-entry checksum manifest reverified, and all six strict
  GitHub attestations passed.

The migration cost is real: a workflow whose old source report label was
absolute gets one unavoidable identity transition, so hosted alerts may show
one-time churn. Outside-workspace files use
external-report/<basename>; duplicate basenames receive sorted ordinals, and
adding/removing one may renumber that group. Scanner-provided locations and
metadata are not sanitized, and successful local SARIF validation still does
not prove that a hosted upload will be accepted.

Independent real-runner feedback is more useful now than another speculative
feature. If you can test a sanitized workflow, please share:

1. runner OS and whether reports were relative, globbed, or outside the checkout;
2. the exported sourceReports[].name values (with sensitive data removed);
3. whether IDs and output bytes remained stable after moving the checkout; and
4. any GitHub/GitLab ingestion behavior, including exact errors.

Please do not post proprietary reports, source paths, credentials, or live
secret findings. Security issues belong in the repository's private reporting
flow.