fix(cli): attach file path and role to SBOM load errors

[dmchaledev]

Summary

When the CLI is given a file that is missing, unreadable, or not valid JSON, main() surfaced the raw low-level error with no indication of which of the two inputs failed or that the SBOM-load step is where it broke. For the tool's headline use case — CI/CD gates — a wrong or corrupt artifact is a common misconfiguration, and the bare message makes it needlessly hard to debug.

Before

$ sbom-diff good.json bad.json
Expected property name or '}' in JSON at position 2 (line 1 column 3)

Which file? Was it even the parse step? No way to tell.

After

$ sbom-diff good.json bad.json
Failed to parse new SBOM 'bad.json': Expected property name or '}' in JSON at position 2 (line 1 column 3)

$ sbom-diff nope.json good.json
Failed to read old SBOM 'nope.json': ENOENT: no such file or directory, open 'nope.json'

Changes

• Add loadSbom(path, label) in src/cli.ts, which reads and parses a file and wraps any failure as Failed to read/parse <old|new> SBOM '<path>': <reason>, distinguishing read failures from parse failures.
• main() now loads both inputs through it (still in parallel via Promise.all). Valid runs are unaffected — exit codes and output are unchanged.
• Tests for the missing-file, malformed-JSON, and happy paths (32 tests pass, up from 29).

Scope / conflicts

Touches only the read/parse path in main() plus a new exported helper and its tests. It does not modify parseArgs, the parser internals, or the report pipeline, so it composes cleanly with the in-flight CLI/parser PRs. Distinct from #21 (validates recognized-JSON-but-unknown-format input) and #40 (BOM stripping) — this is about attaching file context to read/parse failures.

Verification

npm run typecheck, npm run lint, and npm test all pass; behavior confirmed end-to-end against missing, malformed, and valid inputs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JS76safVDXSZwcLRAh8CPv

---

Generated by Claude Code