fix(kubescape): preserve large vulnerability scan writes

[devantler]

Problem

Coroot reports a real storage application error for the Backstage vulnerability manifest:

• Create - save object failed
• write metadata: insert metadata: sqlite: clear bindings: interrupted
• key /spdx.softwarecomposition.kubescape.io/vulnerabilitymanifests/kubescape/ghcr.io-backstage-backstage-1.52.0-993611

The exact manifest is absent afterward, so this is data loss and must not be exempted. The same scan also submits 6,604,113-6,604,551 byte openvulnerabilityexchangecontainers payloads, which the current 1,000,000 byte kind limit rejects.

Root cause evidence

The compatibility image sets SQLite busy_timeout to 60 seconds, but the pinned v0.0.297 storage code obtains every REST connection with pool.Take(poolCtx) where poolCtx expires after five seconds. zombiezen/sqlite binds that context to the connection interrupt for its entire checked-out lifetime. A legitimate foreground write waiting longer than five seconds is therefore forcibly interrupted before the reviewed busy timeout can help, after the payload file has been written but before metadata is persisted.

Acceptance criteria

• Add a failing regression test proving the pool-acquisition timeout cannot interrupt an already acquired connection during a legitimate longer operation.
• Separate the five-second pool-acquisition budget from a finite, longer checked-out connection lifetime without unsafe manual SetInterrupt rebinding.
• Apply the fix consistently to the v0.0.297 compatibility image and publish/pin a signed immutable revision.
• Raise only storage.kindQueues.openvulnerabilityexchangecontainers.maxObjectSize to a finite value above the observed 6.605 MB payload with documented headroom.
• Keep unrelated storage kinds and failure modes fail-visible.
• Verify the Backstage vulnerability manifest and VEX resource are persisted on a fresh scan, storage logs remain clean, and Coroot reports no storage log error after the historical entry ages out.