Cache Trivy vulnerability scanner

[fniessink]

The Trivy vulnerability scanner sometimes fails due to "too many requests". Cache the database?

[wkoot]

We are currently using aquasecurity/trivy-action, which states caching is enabled by default. Do we still see caching errors?
I'm not sure if/how caching worked before, as we seemed to use the same set up at the time of the bug report.
The readme of the action at that point in time however, did not specify it automagically handled caching.
This seems to have been added in aquasecurity/trivy-action#399, so this ticket is hopefully no longer necessary

[wkoot]

All three recent failures of https://github.com/ICTU/quality-time/actions/workflows/trivy.yml at the time of writing are due to a Chromium installation mismatch.
Cache also seems to work, according to run logs:

Cache hit for: trivy-binary-v0.65.0-Linux-X64
Received 37935866 of 42130170 (90.0%), 36.1 MBs/sec
Received 42130170 of 42130170 (100.0%), 39.0 MBs/sec
Cache Size: ~40 MB (42130170 B)
/usr/bin/tar -xf /home/runner/work/_temp/c767470d-2746-4146-ba91-b1b61c6114be/cache.tzst -P -C /home/runner/work/quality-time/quality-time --use-compress-program unzstd
Cache restored successfully
Cache restored from key: trivy-binary-v0.65.0-Linux-X64
Run echo /home/runner/.local/bin/trivy-bin >> $GITHUB_PATH
Run echo "date=$(date +'%Y-%m-%d')" >> $GITHUB_OUTPUT
Run actions/cache@0400d5f644dc74513175e3cd8d07132dd4860809
Cache hit for restore-key: cache-trivy-2025-10-04
Received 33554432 of 52516859 (63.9%), 32.0 MBs/sec
Received 52516859 of 52516859 (100.0%), 45.4 MBs/sec
Cache Size: ~50 MB (52516859 B)
/usr/bin/tar -xf /home/runner/work/_temp/bea99750-affb-4128-a3fc-311a85c3578c/cache.tzst -P -C /home/runner/work/quality-time/quality-time --use-compress-program unzstd
Cache restored successfully
Cache restored from key: cache-trivy-2025-10-04