feat: Handle OpenDAL cache failures and bounded shutdown

Part of #1350. Cache writes may fail or be discarded. The first version must remain correct, release resources and finish shutdown under backend failure; it does not promise durable or eventually successful cache publication.

First-version blockers

• Publish only a successfully written, still-current physical registration. Delayed work and cleanup cannot return another key/version's content or remove an object still owned by a current registration.
• Release pending references and budgets on failure or discard, allowing a later cache miss/refill to retry. Reuse OpenDAL's applicable retry behavior rather than automatically adding another retry subsystem.
• Bound operations and shutdown. State whether close drains or discards admitted work, reject new work after shutdown begins, and specify what wait/close report. They must not silently claim remote completion or wait indefinitely.
• Make background write/cleanup failures observable with bounded bookkeeping. A timed-out write may have succeeded remotely; treating it as uncached and leaving residual cleanup to #1355 is acceptable.
• Verify representative write failure/timeout, failed cleanup and shutdown with pending work. Read errors continue to use the existing get_or_fetch fallback; plain get retains its documented error behavior.

Close this issue once the selected best-effort behavior is implemented, documented and tested. No guarantee of successful physical deletion after a backend failure is required.

Possible follow-ups — not blockers

Durable retry queues, write-ahead/recovery metadata, guaranteed eventual deletion/publication, automatic reconciliation after a lost response, and an exhaustive distributed-failure matrix.

Capacity reclamation remains necessary; strict application invalidation of mutable keys is independent (#1085). Bounds on cleanup/error queues are covered by #1353, and ownership of residual objects by #1355.