docs(matrix): rs reliability rows + stale LAB-426 lock/TTL cells (LAB-518)

[27Bslash6]

Matrix refresh for LAB-518 (cachekit-rs reliability tier, cachekit-io/cachekit-rs#43):

• Flipped to ✅ for Rust (with evidence notes): circuit breaker, retry (row added), graceful degradation (row added), cache stampede prevention. Backpressure stays honestly ❌ — not in LAB-518's acceptance criteria.
• Fixed stale rs cells: distributed locking said "SaaS backend only; Redis/Workers lack impls" and TTL said "Workers ❌" — LAB-426 already shipped both (code-verified redis.rs:165, workers.rs:262/322). Leaving those lies in rows this PR edits would be exactly the trust-bug class the doc gate exists for.
• Rust SDK summary block updated (feature flag list + reliability bullet).

Python/TypeScript cells in the new Retry / Graceful degradation rows follow the LAB-275 audit's code-verified verdicts.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 58 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 42be655f-6c63-4b70-b0fd-53f09c6e45c9

📥 Commits

Reviewing files that changed from the base of the PR and between 53aaec8 and 79d4e58.

📒 Files selected for processing (1)

• sdk-feature-matrix.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch lab-518-matrix-rs-reliability

---

_{Comment @coderabbitai help to get the list of available commands.}

[27Bslash6]

Auto-rebase attempt: merged origin/main and hit real content conflicts in sdk-feature-matrix.md — this branch (LAB-518, rust reliability: circuit breaker/retry/graceful-degradation/stampede rows) and main (ts backpressure/stampede LAB-519, plus the standing rust-Workers-locking discrepancy from LAB-426/427) both rewrote the same table block with different, non-additive changes. Splicing requires reconciling which rust capability claims are current — not a safe mechanical union. Left for a human call. Merge aborted, branch untouched.

[27Bslash6]

Auto-rebase check: merging origin/main into this branch conflicts in sdk-feature-matrix.md across 3 hunks. This branch adds new reliability rows (Retry, Graceful degradation) not present on main, but also has cells that now contradict main's content on overlapping capabilities (e.g. Rust circuit breaker ✅ here vs ❌ on main; stampede-prevention and locking details differ from the LAB-426/LAB-429/LAB-519 updates already on main). Not a clean union — needs a human call on which capability claims are current.

[27Bslash6]

Auto-rebase attempted a merge of origin/main and hit a real conflict in sdk-feature-matrix.md — needs a human call, not left as-is:

• Both branches edited the same table rows (Circuit breaker, Backpressure, Distributed locking, Cache stampede prevention, TTL management) with different, overlapping SDK-status content (this PR's LAB-518 rs reliability updates vs. main's LAB-446/LAB-519/LAB-595/LAB-272 updates).
• Also two different "Last updated" narrative summary lines at the top of the doc.

Resolving this correctly means merging facts from both sides cell-by-cell (e.g. keeping this PR's Rust circuit-breaker/stampede info and main's TypeScript backpressure/stampede info in the same row) rather than picking one side — that's a judgment call I'm leaving for you. Branch left untouched (merge aborted, no push).

[27Bslash6]

Auto-rebase: conflict in sdk-feature-matrix.md — both branches wrote contradictory feature-status values for the same table rows (Circuit breaker, Backpressure, Distributed locking, Cache stampede prevention, TTL management for Rust/TypeScript). This isn't a textual union — reconciling which claims are current needs a human call.

[27Bslash6]

auto-rebase: sdk-feature-matrix.md conflicts overlap on the same rows (Circuit breaker / Backpressure / Distributed locking / TTL management for Rust) with different substantive content from each side — resolving means picking one side's facts over the other's, not a mechanical union. Needs a human call.

[27Bslash6]

Conflict in sdk-feature-matrix.md (3 hunks). Reliability Features table hunk is a real content conflict, not just reformatting: this PR's HEAD adds two new rows (Retry, Graceful degradation) absent from origin/main entirely, and the Circuit breaker/Rust cell directly contradicts between sides (✅ vs ❌). Combining requires editorial judgment about which facts are current — not a mechanical merge. Leaving for a human to resolve.