[matiasdaloia]

Stacked on #98 (base feat/snippet-classifier). Merge #98 first; this PR then retargets to main.

What

The options the snippet classifier needs to ship (scanoss/roadmap#14):

• --classify-threshold <float>: P(false positive) at or above which a match is proposed as a false positive. Default 0.7, strictly between 0 and 1, only valid with --classify-snippets.
• --classify-filter: removes snippet matches proposed as false positives, and components left with no evidence.
  • Advisories that only pointed at removed components go too, so no output keeps a dangling reference.
  • File matches, dependency evidence, unscored snippets and matches claimed by a bom.identify rule are never removed.
  • Filtering runs before enrichment, so removed components never reach the vulnerability or license services.
• Every output format. --classify-snippets is no longer raw-only.
  • CycloneDX: occurrences have no properties, so the verdict follows the ranges in additionalContext: input lines 19-405; oss lines 19-405; classifier real p=0.00 model=lr-d51f2e100211.
  • SPDX-lite: it has no per-file data, so it carries no verdict. Filtering still applies.
• A summary on stderr, e.g. Snippet classifier (model lr-d51f2e100211, threshold 0.7): scored 54 of 54 snippet matches, 3 proposed as false positives, 3 removed. It warns when matches could not be scored, and says so when file contents answer 401/403. Before this, those failures were only logged.
• The file-contents id is the scan's file_hash, a 16-hex CRC64 today, not an MD5. Only the wording changes.
• Docs: CHANGELOG [Unreleased] (covering --classify-snippets too, which feat(scan): classify snippet matches as false positives (opt-in) #98 had no entry for), README and CLIENT_HELP.

Why the filtering guidance says 0.9

On 8 public application repos (876 snippet matches, blind stratified review of 109) the released model gives FP precision 0.71 and recall 0.90 at 0.7; at 0.9 it gives 0.79 and 0.83. Details are in the comment on #98. 0.7 is fine for proposing; filtering drops some real matches, so the docs advise a higher threshold and say filtering never replaces review.

Testing

• make fmt-check, make vet, make test: pass. go test -race on snippetmatch, scanpipeline, sbom and cmd: pass.
• make lint was not run locally: the installed golangci-lint (built with go1.25) refuses the go1.27 toolchain. CI runs it.
• New tests cover:
  • threshold validation and flag dependencies;
  • filtering: evidence removed, empty components removed, advisories pruned, file, unscored and identified matches untouched;
  • the CycloneDX context text and the summary counts.
• Each filtering guard was broken on purpose to confirm a test fails.
• Live against api.scanoss.com, on TheAlgorithms/Java (54 snippet matches):
  • --classify-filter: 3 proposed and 3 removed, no false-positive verdict left in the raw output.
  • -f cyclonedx: verdict present in additionalContext.
  • --classify-threshold without --classify-snippets, and a threshold of 1.5, are both rejected before upload.