[droplister]

Summary

• add opt-in durable cache publication for expensive D1-backed producers
• retry only the explicit D1 DB is overloaded condition with bounded backoff
• enable durable publication for collection candidates
• keep existing best-effort cache behavior for ordinary endpoints

Why

The optimized cold collection-candidates request now completes successfully in about 5.2 seconds, but the immediately following cache INSERT was rejected while D1 was still saturated. cached() swallowed that write failure, leaving no cache row and guaranteeing the next caller would recompute the expensive result. This is the overload feedback loop identified in the resource audit.

The durable mode waits 250ms, 750ms, 2s, and 4s between bounded retries. A successful cold response is not returned until its daily cache row is durable. Schema, authentication, and other logic errors are never retried.

Verification

• cache retry unit test proves transient overload recovery and immediate failure for non-overload errors

pm test -w xcp-api: 470 passed, 0 failed (34 live-contract tests skipped locally by design)

pm run check: typecheck, ESLint, Prettier, and structure checks passed