fix: add download size limit for OSV database archives

[JasonOA888]

Summary

The HTTP response body from OSV database archive downloads was read with io.Copy without any size limit. A compromised or malfunctioning CDN endpoint could serve an arbitrarily large response, causing disk exhaustion on the scanning machine.

Fix

Wrap resp.Body with io.LimitReader capped at 1GB:

// Before
_, err = io.Copy(f, resp.Body)

// After
_, err = io.Copy(f, io.LimitReader(resp.Body, maxDownloadBytes))

1GB provides ample headroom — the largest OSV database zip (osv-vulnerabilities/OSV) is ~350MB as of April 2025.

Why this matters

This is a supply-chain defense measure. The download URL (ArchiveURL) targets Google Cloud Storage, which is trusted. But if that endpoint were compromised (bucket hijack, DNS poisoning, CDN injection), the scanner would blindly write unlimited data to disk. io.LimitReader makes the failure mode bounded and deterministic.

Testing

Added TestNewZippedDB_Online_OversizedResponse to verify the LimitReader does not break normal downloads (generating a >1GB payload in a unit test is impractical, so the test confirms the happy path still works with the limit in place).

All existing tests in zip_test.go continue to pass as the limit (1GB) far exceeds their test payloads.

[JasonOA888]

The CI failures on all three platforms (ubuntu, macos, windows) appear to be caused by api.osv.dev being unreachable from the CI environment, not by the changes in this PR.

The failing tests (TestCommand_Transitive, TestCommand/update_*) are integration tests that make real HTTP calls to the OSV API. Our change only modifies the local zip archive download path in internal/clients/clientimpl/localmatcher/zip.go to add a size limit via io.LimitReader.

This looks like a flaky CI run due to external service unavailability. Happy to rebase or push an empty commit to retrigger CI if needed.