docs(matrix): flip rs Redis-lock + Workers lock/TTL cells (LAB-426)

[27Bslash6]

Part of LAB-426 (docs gate). Flips the Rust capability cells the LAB-273 audit left ❌:

• Optional capabilities table: rs TtlInspectable Workers ✅; rs LockableBackend Redis ✅ + Workers ✅, with the Redis mechanism recorded inline (SET NX PX + Lua compare-and-delete, <key>:lock namespace shared with cachekit-py).
• Reliability table: Distributed locking → "Redis + SaaS + Workers"; TTL management → "Redis + SaaS + Workers".
• Coverage callout rewritten: Python and Rust now cover both capabilities on every capability-bearing backend; the remaining gap is TypeScript's Redis backend (LAB-427).
• Last-updated banner bumped.

Evidence: cachekit-io/cachekit-rs#37 — three impls plus literal wire-JSON round-trip tests (snake_case contract, camelCase tripwire per LAB-411) and a live-Redis lock-semantics integration test.

⚠️ Merge ordering: merge this only after (or together with) cachekit-rs#37 — the cells describe that PR's code.

[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: 49 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: 4fb1e1cf-b516-4f7b-9352-5cebe0f6c4e0

📥 Commits

Reviewing files that changed from the base of the PR and between 8ba5ef9 and 54d137b.

📒 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-426-matrix-rs-capability-cells

---

_{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-426) claims Rust Workers now has distributed locking (✅ rs#37), while main's version (from a different landed PR) explicitly states Workers ❌ (no impl). These are contradictory factual claims about the same capability cell, not a non-overlapping union — resolving requires knowing which is actually true post-merge. 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 4 hunks — both sides edited the same capability-matrix cells with contradictory content (this branch documents Rust Workers gaining lock/TTL via rs#37 and TS Redis still lacking lock/TTL; main documents LAB-427/LAB-429/LAB-519 already shipped, with TS Redis now having lock/TTL and Rust Workers still lacking lock). Resolving would mean picking one side's shipped-capability claims over the other's — needs a human call on which facts are current.

[27Bslash6]

Auto-rebase attempted a merge of origin/main and found a genuine content conflict in sdk-feature-matrix.md — both sides edited the same capability-matrix rows with contradicting claims (e.g. this branch says Rust Workers distributed locking is ✅ (rs#37), origin/main says ❌). Resolving would mean picking one side's data over the other's, so left for a human call.

[27Bslash6]

Auto-rebase sweep: merging main conflicts in sdk-feature-matrix.md. This branch (LAB-426, Rust capability cells) and main both edited the same rows — TTL inspect/refresh, Distributed locking, Backpressure, Cache stampede prevention — for different columns/SDKs with contradictory state (e.g. this branch says Rust Workers locking ✅/rs#37; main's merged history says Workers ❌ per LAB-427/LAB-102), plus the "Last updated" and footnote text. Overlapping edits to the same cells — not a safe mechanical union. Left for a human to reconcile.

[27Bslash6]

Auto-rebase found a real conflict in sdk-feature-matrix.md — needs a human call. Multiple hunks are contradictory factual claims about the same capability cells, not independent additions — e.g. this branch (LAB-426) states Rust Workers gained distributed locking + TTL inspection via rs#37 (✅), while main states Rust Workers locking still lacks an implementation (❌) for the same capability. The "Last updated" changelog line and the reliability-features table have the same kind of overlapping edits from several concurrent LAB tickets (427/430/446/519/595/272 etc.) already landed on main. Reconciling this needs someone who knows which claims are actually current — left the branch as-is; will retry once main moves again.

[27Bslash6]

Auto-rebase attempted, left for a human: merging main conflicts in sdk-feature-matrix.md — both sides edited the same "Last updated" line and the same TTL-inspect/distributed-locking/backpressure table rows and footnote with different ticket-driven content (this branch: LAB-426 Rust Redis/Workers locking+TTL; main: LAB-729/LAB-519/LAB-446/LAB-430 backpressure/TTL/lock updates). Needs a human to synthesize both sets of matrix edits.

[27Bslash6]

Auto-rebase attempted a merge from main but hit content conflict in sdk-feature-matrix.md — same shared table other open siblings (#17, #28, #29, #31) also conflict on, with differing factual claims per cell rather than a non-overlapping union. Needs a human call. Left branch untouched (no push).