fix: add acceptance test to ensure cache access isolation

[itslenny]

What kind of change does this PR introduce?

Add acceptance check to ensure private accesses are not available via public endpoint.

[coveralls]

Coverage Report for CI Build 29852916008

Coverage increased (+20.7%) to 79.785%

Details

• Coverage increased (+20.7%) from the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	12786
Covered Lines:	10648
Line Coverage:	83.28%
Relevant Branches:	7476
Covered Branches:	5518
Branch Coverage:	73.81%
Branches in Coverage %:	Yes
Coverage Strength:	432.2 hits per line

---

💛 - Coveralls

[claude]

LGTM to merge — the two nits flagged inline (potential testTimeout margin from the higher CACHE_RETRIES, and the new BYPASS check's retries masking transient leaks) are test-only and don't block this PR.

Extended reasoning...

Overview

This PR only touches acceptance/specs/cdn.test.ts: it raises SIGNED_EXPIRES_IN_S and CACHE_RETRIES to reduce acceptance-test flakiness, replaces a conditional webhook pause with a fixed 5s delay in the transform-caching test, and adds a new regression check that a private/authenticated object's transform cannot be served through the public route/cache.

Security risks

None — this is acceptance-test code only, no production source is changed. The new check is itself a security-relevant test (verifying no cross-tenant/cross-bucket cache leak via the public route), which is a good addition in principle.

Level of scrutiny

Low-to-moderate. Test-only diff, no risk to production behavior; worst case is test flakiness or a masked regression check, both non-destructive and already called out in the inline nits.

Other factors

Both findings from the bug-hunting pass are correctly scoped as nits: the timeout-margin issue is probabilistic and only manifests under degraded conditions, and the retry-masking issue only hides a transient (self-correcting) leak — a persistent leak would still be caught. The one other candidate issue raised (unconditional 5s delay for non-signed methods) was reviewed and ruled out as not a real bug. Given the low blast radius of test-only changes, these nits don't warrant blocking merge.