feat: [stable-9.0][OCISDEV-855] port CAS hardening - #776

Ports OCISDEV-855's CAS-conflict hardening in the jsoncs3 share caches (receivedsharecache/sharecache/providercache: TooEarly/Unavailable retry, NotFound-safe resync, Aborted/AlreadyExists status mapping) forward onto stable-9.0, which never received it — only stable-8.0 did.

Load test results

baseline: avg 113.44ms / p95 578.53ms / p99 978.76ms — https://github.com/owncloud/ocis/actions/runs/38402514762
baseline: avg 111.97ms / p95 655.65ms / p99 1150ms — https://github.com/owncloud/ocis/actions/runs/39415555808
branch:   avg 116.25ms / p95 590.62ms / p99 968.29ms — https://github.com/owncloud/ocis/actions/runs/39386035776
branch:   avg 115.29ms / p95 620.13ms / p99 993.4ms — https://github.com/owncloud/ocis/actions/runs/39413254463

p95/p99 are flat-to-improved. The ~2-3ms avg gap was investigated to find a code-level cause and none was found:

• Every line changed by this port sits behind a CAS-conflict/download-error branch; the happy path (no conflict) is byte-for-byte identical to baseline (verified via diff against the actual baseline pin 8b649a4c3).
• The retry/backoff mechanics themselves were benchmarked old-vs-new under simulated contention (correct CAS semantics: a write stays stale until a successful download resyncs the etag) — the new code is faster in every tested scenario, e.g. triple-TooEarly-resync: 8.5ms (old) vs 4.0ms (new) with no network latency, 56ms vs 31ms with simulated network latency.
• Both compared k6 runs report http_req_failed: 0.00% and near-identical request/iteration counts (633/356 vs 642/360), ruling out a hidden-retry or confounded-sample explanation.
• The ocis-side A/B (aab12d018e3 vs the reva-bump branch) is a clean linear 5-commit chain with no unrelated ocis-native changes.

No code mechanism accounts for the avg gap; isolating it further would require per-request-tag k6 output, which isn't currently capturable (the deployed k6 test wrapper pipes its own --out to the Grafana dashboard, outside this repo).