fix: summarization retries panicked in debug, and a test relied on it

[yuanhao]

Found by the test-coverage review of #155, outside the question it was asked.

The bug

RetryConfig::delay_for_attempt documents a 1-indexed attempt and computes attempt - 1. llm_compaction.rs passed the raw 0..=max_retries loop variable, so the first retry underflowed usize and panicked in debug builds. agent_loop.rs increments before calling and was correct — this was confined to compaction.

The code even writes attempt + 1 for its own log message a few lines above, so the 0-indexing was known locally and lost at the call.

It landed on a detached task, so nothing surfaced. The summarization simply vanished, no briefing arrived, and compaction fell back deterministically — which is one of the behaviours #150 was filed about. Verified directly:

thread '...' panicked at src/retry.rs:47:73: attempt to subtract with overflow

delay_for_attempt now uses saturating_sub, so a caller that misses the 1-indexed contract loses the backoff rather than the task. Both call sites are corrected to pass attempt + 1.

A test was passing because of the panic

provider_failure_falls_back_deterministically asserts that a failed request leaves the in-flight slot idle, and checks after 100ms. Its FailingProvider returns a retryable error — so the instant panic-death released the slot well inside that window.

With retries actually working, the first backoff is ~1s and the slot is legitimately still held, so the test failed. It now configures RetryConfig::none(): it is about the drop guard, not about backoff timing. The reason is written into the test so it isn't "fixed" back later.

Coverage hole from #155 that I had missed

Deleting the only warn_losing_race_once() call site in compact() disconnects the entire feature — the counter never moves for any real user — and every test stayed green, because they all call the function directly. compact_counts_real_fallbacks_and_warns_on_the_streak now drives the real path through compact(); deleting the call site fails it.

I should flag that I briefly reported this mutation as already caught. It wasn't — the suite was red at the time from the retry fix above, and I read a pre-existing failure as a catch. Re-verified against a green baseline before and after.

Verification

mutation	result
restore (attempt - 1)	attempt to subtract with overflow
delete the warn_losing_race_once() call site	each deterministic compaction must advance the streak
delete the discard-path counter	must advance the streak, not clear it

cargo test --all-features: 627 passed, 0 failed. Clippy clean under -Dwarnings.

🤖 Generated with Claude Code