fix(reliability): clamp max_concurrent to Semaphore::MAX_PERMITS; add ReliabilityConfig::disabled() (LAB-729)

[27Bslash6]

Applies the surviving findings from the formal expert-panel review of the merged #49 (LAB-729), run 2026-07-28 at high stakes on Ray's request (panel: bug-hunter-supreme, security-specialist, code-craftsman, catchphrase-agent).

Panel verdict on #49: FIX-FIRST → this PR

• MAJ (bug-hunter, verified by executing it): Semaphore::new(max_concurrent.max(1)) panics when max_concurrent > tokio::sync::Semaphore::MAX_PERMITS (usize::MAX >> 3). usize::MAX is the natural "effectively unbounded" sentinel a user of this public config will reach for, and it crashed inside CacheKitBuilder::build() with tokio's internal panic. Now clamped to [1, MAX_PERMITS], documented on the field next to the existing "0 behaves as 1" note, pinned by limiter_clamps_huge_max_concurrent_instead_of_panicking.
• MIN (craftsman): the builder's wrap-or-skip gate hand-enumerated each layer's is_some() — the exact shape that shipped a missed-layer bug once already inside feat(reliability): backpressure — bound backend-op concurrency (LAB-729) #49's own history. The check now lives on ReliabilityConfig::is_disabled(), beside the fields, so a future fourth layer cannot silently miss the gate.
• MIN (craftsman): the documented opt-out was a full struct literal, which breaks every downstream opt-out each time the stack gains a layer (twice now). ReliabilityConfig::disabled() replaces it in the README, builder rustdoc, and preset docs (doctest-covered).

Rejected, with reason

• MIN (craftsman): dedupe the bounded-poll test helper across macro_tests.rs / reliability_tests.rs. Rejected — the "fix" is a closure-parameterized generic helper in tests/common, which costs more machinery than the eight duplicated test-scaffold lines it removes; the catchphrase reviewer's own pass reached the same conclusion for the sibling test fixtures. Revisit if a third copy appears.

Clean passes

• security-specialist: NO FINDINGS — verified the secure path still fails closed on a shed (empty fail-open arm at both macro splice sites), shed messages carry no secrets (CWE-532), and the in-process limiter crosses no trust boundary.
• catchphrase-agent: NO CUTS — "appropriately simple: every layer earns its place"; all three config knobs, the RAII guards, and the test weight ruled load-bearing.

Gates: fmt, clippy -D warnings, 244 tests + 8 doc-tests, 0 failures.

This PR contains only the panel's own prescriptions; the panel report on LAB-729 covers it.

[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: 41 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: f38a0fb4-7683-40bd-ad41-901b63dbd1b3

📥 Commits

Reviewing files that changed from the base of the PR and between 8173e91 and 0019637.

📒 Files selected for processing (4)

• README.md
• crates/cachekit/src/client.rs
• crates/cachekit/src/intents.rs
• crates/cachekit/src/reliability.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch lab-729-panel-followup

---

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

[kodus-27b]

Kody Review Complete

Great news! 🎉
No issues were found that match your current review configurations.

Keep up the excellent work! 🚀

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​