[matiasdaloia]

Why

Customers want to choose how many components a scan reports. scanoss.api now takes a max_components query parameter on POST /v3/wfp/scan: a base-10 positive integer (leading zeros allowed) or exactly all. In chunked mode every upload block of a session must carry the same value or the server answers 400. This PR lets SDK and CLI users send it.

Server semantics: N is the best N components of the project ranking for full-file matches, plus up to 3 context picks (folder, file alone, origin) labelled in each match's context. A snippet block gets up to N candidates, and the allowed set widens to at least N. all means no limit.

Scope

• pkg/scanoss: ComponentLimit (zero value = unset), ComponentsUpTo(n), AllComponents(), ParseComponentLimit(s), IsSet(), String(), and WithMaxComponents(l). When set, the parameter is added to every chunk upload of the scan, built with url.Values.
• CLI: --max-components on scan and scan wfp. It is parsed before fingerprinting or uploading, so an invalid value, or an explicitly empty one, fails with no request sent. results does not take it (it only polls).
• Docs: README, CLIENT_HELP.md, CHANGELOG.md.
• Not included: no scanoss.json key, no change to libscanoss/.

Default: unset sends no max_components parameter. Requests are byte-identical to today and the server defaults apply (2 for full-file matches plus the context picks, 1 per snippet block).

The scanoss.api server must support the parameter. A server that does not will ignore it.

Blast Radius

Unset callers: none, no query string is added. Users of the new option or flag against a server without support get the server defaults silently. uploadChunks and uploadChunk are unexported and gained a query argument. scanTuning gained a components argument. The branch was rewritten from the earlier max_candidates_per_match naming into two commits on main.

Verification

• go test ./..., go vet ./... and gofmt -l cmd pkg are clean.
• make lint could not run locally: the installed golangci-lint is built with go1.25 and the module targets a newer Go.
• Tests (renamed with the API): a recording httptest server over a 4-chunk upload asserts max_components=5 and =all on every chunk and an empty query when unset; a ParseComponentLimit table (007 accepted; 0, -1, 2.5, empty, 3, 3 , ALL, +3, 1e3, 0x10, overflow rejected); a 400 on one block fails the scan with the status named; a block that first gets a 503 carries the parameter on the failed attempt and on its retry; CLI tests assert invalid and explicitly empty values error naming the flag with zero requests seen, and valid values reach every upload block, through both scan wfp and scan <dir>.
• The behaviour is unchanged from the earlier revision, whose tests were each checked by breaking the behaviour; this rework is a rename and was not re-broken.