fix(clamav): raise WRITE_TIMEOUT_SECONDS past the scan timeout

[netomi]

Related to #13794.

Summary

• clamav-rest (EclipseFdn/clamav-rest-new) defaults WRITE_TIMEOUT_SECONDS to 300s and we never override it in any values file. Go's http.Server.WriteTimeout is reset when the request's headers are read and bounds the entire handler-to-response-write duration, so for any scan slower than 300s the server severs the connection well before SCAN_TIMEOUT_MINUTES elapses.
• The scan keeps running after the connection is cut, but its result is written to a connection nobody is listening on anymore — the calling openvsx server sees a bare Read timed out instead of the scan verdict, and ExtensionScanCompletionService marks the scan group ERRORED even though clamav-rest's own logs show a clean, completed scan.
• This reproduced in production for Oracle.oracle-java, whose VSIX (2398 files) scans in ~394s — comfortably past the undocumented 300s cutoff but still under the configured 10-minute SCAN_TIMEOUT_MINUTES.
• Fix: set WRITE_TIMEOUT_SECONDS above SCAN_TIMEOUT_MINUTES * 60 everywhere clamav.env is defined (base values.yaml, values-aws.yaml, values-aws-staging.yaml), so the configured scan timeout is the one that actually governs. values-aws-dr.yaml has clamav disabled and values-staging.yaml/values-test.yaml don't override env, so they inherit the base fix.

Test plan

• Deploy to staging and publish a large extension whose scan runs past 5 minutes (current staging SCAN_TIMEOUT_MINUTES); confirm the scan result now lands rather than erroring out.
• Re-publish Oracle.oracle-java 27.0.0 (or a comparably large version) in production and confirm the scan completes without the group being marked ERRORED.

🤖 Generated with Claude Code

[netomi]

please merge at your convenience so that the clamav service takes the correct timeout into account