LAB-520: feature-matrix row for cross-instance L1 invalidation

[27Bslash6]

Adds the "Cross-instance L1 invalidation (pub/sub)" row to Reliability Features per the LAB-520 decision:

• TypeScript ✅ — opt-in invalidation config, Redis pub/sub channel (the shipped reference implementation).
• Python ❌ — the complete-but-never-wired invalidation package was deleted (refactor!: remove unwired cross-instance invalidation package (LAB-520) cachekit-py#237) rather than wired: without server-side key tracking, broadcasting mass invalidations would have other pods evict L1 and immediately re-read stale L2 entries the invalidating process couldn't delete.
• Rust ❌ — nothing exists.

Footnote also records that invalidation events are not cross-SDK interoperable (no protocol spec; ts channel name/payload differ from what py's package used) so nobody mistakes the ts channel for a protocol surface.

No spec/test-vector/byte-format changes — matrix documentation only.

[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: 57 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: 54b1268f-ac2b-4fd8-b0e6-08051f9feffb

📥 Commits

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

📒 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 agent/winston/02318f2d

---

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

[27Bslash6]

Conflict in sdk-feature-matrix.md (the "Last updated" summary line — same recurring pattern as the other protocol PRs in this sweep: both this branch and main wrote a different narrative summary onto the same line). Picking one drops the other's content, so this needs a human call.

[27Bslash6]

Auto-rebase attempted: merging origin/main produced multiple conflicting hunks in sdk-feature-matrix.md — overlapping edits to the same table/sections on both sides. Not a safe auto-union — needs a human call. Left the branch untouched.

[27Bslash6]

Auto-rebase attempted a merge of main but hit 2 conflict hunks in sdk-feature-matrix.md: the shared "Last updated" changelog line (this branch's LAB-520 entry vs main's larger LAB-446/LAB-595/LAB-519/LAB-272 entry -- same line, different text, not a mechanical union) and a footnote-number collision (this branch's new footnote reuses digit "3", already used elsewhere in the file for an unrelated Rust-backend note). Left for a human to reconcile.

[27Bslash6]

Auto-rebase sweep: merging main conflicts in sdk-feature-matrix.md. This branch (LAB-520) and main both edited the same shared table cells — Backpressure, Distributed locking, Cache stampede prevention, TTL management — with different, non-overlapping-in-intent text (main folds in LAB-519/LAB-430/LAB-446/LAB-272 updates this branch doesn't have), plus conflicting "Last updated" summary lines and footnote numbering. Not a safe mechanical union — needs a human to reconcile the table by hand.

[27Bslash6]

Merge conflict against main in sdk-feature-matrix.md, two blocks:

• The "Last updated" summary line (each branch stamped its own changelog entry).
• A footnote block where this branch adds footnote ³ (Python invalidation-package removal, LAB-520) at the same anchor point where main has independently added a TypeScript backpressure-decision note plus a per-backend TTL-management note — different content, same location, and both use the ³ marker. A blind union risks colliding footnote numbering and misordering unrelated notes.

Not a safe automated resolution — needs a human to reconcile the footnote numbering and merge order (same shared-file conflict pattern as the sibling protocol matrix PRs currently stacked on main).

[27Bslash6]

Auto-rebase check: base main has moved (main HEAD 936f22f) and this branch now conflicts in sdk-feature-matrix.md — overlapping edits to the same capability-matrix rows/notes as main's newer content. Needs a human call, not safe to auto-resolve.

[27Bslash6]

Auto-rebase attempted, left for a human: merging main conflicts in sdk-feature-matrix.md — both sides edited the same "Last updated" line, the same Backpressure/Distributed-locking/Cache-stampede/TTL-management table rows, and the same footnote block with different ticket-driven content (LAB-520 cross-instance invalidation on this branch vs. LAB-729/LAB-519/LAB-446/LAB-430 on main). Synthesizing both sets of changes into one coherent matrix needs a human call, not a mechanical merge.

[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) also conflict on, with differing factual claims per cell rather than a non-overlapping union. Needs a human call. Left branch untouched (no push).