GeezerVison

Token-less (free-user) scans previously issued one GET
/patch/by-package/:purl per package against the public proxy because
the proxy had no batch endpoint. The depscan firewall-api-proxy now
exposes POST /patch/batch (filtered to free-tier patches, served
no-store), so proxy-mode search_patches_batch POSTs the same
CycloneDX-style components body it already sends to the authenticated
/v0/orgs/{slug}/patches/batch endpoint — one request per --batch-size
chunk instead of one per package.

Deployments that predate the proxy endpoint still work: the client
detects the legacy catch-all (400 "Unsupported endpoint"), a missing
route (404/405), or an unconfigured patch API (503 "Patch API is not
configured") and degrades to the per-package GET path. Genuine
validation 400s, rate limits, and over-capacity 503s surface instead
of silently degrading — the latter so an overloaded proxy is not hit
with a tenfold request amplification.

The 400/503 body markers are a cross-repo contract with the depscan
proxy; documented on the helper. Covered by an is_batch_unsupported
unit-test truth table and a wiremock integration suite asserting which
HTTP calls fire (batch POST vs per-package GET fallback) per response.

Assisted-by: Claude Code:claude-fable-5

# Conflicts:
#	CHANGELOG.md

The proxy batch endpoint validates its component list all-or-nothing,
so a single crawled PURL of a type the server doesn't recognize (e.g.
pkg:jsr/... from the Deno crawler) rejected the whole chunk and, when
every chunk contained one, flipped the entire scan to exit 1. The
docker e2e deno JSR test caught this against the production proxy:
scan crawled 4 jsr packages, the one batch POST 400'd, and the scan
errored where the old per-package GET path had quietly tolerated the
unresolvable PURLs one by one.

A validation 400 on the proxy batch POST now degrades the chunk to the
legacy per-package GET path, whose per-PURL error swallowing is the
scan semantic that predates the batch optimization: the valid subset
still resolves, the exotic PURLs stay patch-less, and the scan
succeeds. Rate limits, auth statuses, and over-capacity 503s still
surface. is_batch_unsupported keeps detecting deployment-level absence
only; the two fallback causes are logged distinctly.

Verified against the real patches-api.socket.dev with a synthetic JSR
layout: scan now exits 0 with scannedPackages=4 and the debug trace
shows batch POST -> validation 400 -> 4 tolerated per-package GETs.

Assisted-by: Claude Code:claude-fable-5