[Feature] imageVerifyCacheMaxSize default (1000) may be too small for byte-costed attestation payloads

Problem Statement

Follow-up from #17164. payloadCost() (pkg/image/verification/cache/client.go) now charges real payload bytes as ristretto cost for attestation cache entries, but the production default --imageVerifyCacheMaxSize=1000 (cmd/internal/flag.go) was sized for the old flat "1000 keys" semantics. A single real attestation payload (e.g. a multi-KB CycloneDX SBOM) can approach or exceed that whole cost budget on its own.

Under default settings this means the attestation cache may rarely retain payloads at all -- writes get silently rejected by ristretto once the cost budget is exhausted. This does not reopen the security issue #17164 fixes: a rejected write just means a clean cache miss and full re-verification on the next admission, which is still correct and fail-closed. It's a caching-effectiveness gap, not a correctness one.

#17164 adds logging so a rejected write is now visible (cache write rejected: attestation payload was not cached, possibly exceeding --imageVerifyCacheMaxSize), but the underlying sizing mismatch remains.

Solution Description

Options to consider:

• Raise the default --imageVerifyCacheMaxSize to a value that comfortably fits typical attestation payload sizes.
• Introduce a separate, explicitly byte-based sizing flag (e.g. --imageVerifyCacheMaxBytes) so operators can reason about memory directly, decoupled from the old "number of keys" semantics.
• At minimum, update the flag's help text, which still says "Maximum number of keys" even though cost is now byte-based.
• Decouple NumCounters from --imageVerifyCacheMaxSize. It is currently 10 * maxSize (pkg/image/verification/cache/client.go), which made sense when cost meant entry count, but ristretto sizes counters per expected item (~3 bytes each). With byte-based cost, a 50 MB limit would imply ~500M counters (~1.5 GB). Any fix that raises the limit should size NumCounters from an expected entry count instead. (Raised by Copilot on #17164.)

Alternatives

No response

Additional Context

Traced while addressing review feedback (Copilot + @JimBugwadia) on #17164.

Slack discussion

No response

Research

• I have read and followed the documentation AND the troubleshooting guide.
• I have searched other issues in this repository and mine is not recorded.