Keep longer backoff for persistent non-rate-limit errors

calculateAuthProfileCooldownMs now returns a flat 30s for every non-billing failure, but computeNextProfileUsageStats uses this path for reasons like auth, model_not_found, format, and unknown (not just rate_limit). In persistent misconfiguration cases (e.g., invalid credentials classified as auth), this change makes the same broken profile re-enter rotation every 30s indefinitely, creating repeated failing calls/log churn where the previous backoff quickly reduced retry pressure; consider scoping the flat cooldown to true rate-limit/transient reasons only.

Useful? React with 👍 / 👎.

tests in src/agents/auth-profiles.markauthprofilefailure.test.ts:201-209 expect old exponential behavior and will fail

This is a comment left during a code review.
Path: src/agents/auth-profiles/usage.ts
Line: 278-285

Comment:
tests in `src/agents/auth-profiles.markauthprofilefailure.test.ts:201-209` expect old exponential behavior and will fail

```suggestion
export function calculateAuthProfileCooldownMs(errorCount: number): number {
  // Kai fork: flat 30-second cooldown replaces exponential backoff.
  // Original formula: 60s * 5^(errors-1), capped at 1 hour.
  // At 3 errors = 25 min, 4 errors = 60 min — way beyond Anthropic's actual limits.
  // Author: Teodor 🔧 (Feb 18, 2026)
  void errorCount; // preserve signature
  return 30 * 1000;
}

// Note: Update tests in markauthprofilefailure.test.ts to expect 30_000 for all error counts
```

How can I resolve this? If you propose a fix, please make it concise.

Keep non-rate-limit failures on a longer cooldown

Returning a hard-coded 30s here applies the same retry cadence to persistent failures, not just throttling: classifyFailoverReason emits values like session_expired/model_not_found (src/agents/pi-embedded-helpers/errors.ts:916-921), and maybeMarkAuthProfileFailure records every non-timeout reason (src/agents/pi-embedded-runner/run.ts:663-670). With this change, those misconfigured or expired profiles re-enter rotation every 30 seconds indefinitely, causing repeated failed attempts and log churn in production where the previous backoff reduced retry pressure over time.

Useful? React with 👍 / 👎.

Align flat cooldown with documented 60s rate-limit window

Returning a hard-coded 30_000 here causes retries to happen before the rate-limit window you describe in the same function comments as "Anthropic ~60s" has elapsed, so single-profile setups will incur at least one avoidable extra failed request after each throttle event. Because markAuthProfileFailure reapplies this same cooldown on every rate_limit failure, sustained throttling can devolve into a 30-second fail loop with unnecessary API/log churn; this should use a window that is at least as long as the documented provider limit or be provider-specific.

Useful? React with 👍 / 👎.

Restore stronger backoff for persistent profile failures

calculateAuthProfileCooldownMs now hard-codes 30_000 for every failure, but computeNextProfileUsageStats applies this path to all non-billing/non-auth_permanent reasons, not just throttling (src/agents/auth-profiles/usage.ts, computeNextProfileUsageStats). In the runner, markAuthProfileFailure is recorded for every non-timeout failover (src/agents/pi-embedded-runner/run.ts:656-670), so persistent misconfigurations like auth, model_not_found, or format will re-enter rotation every 30 seconds indefinitely, causing repeated upstream failures/log churn where the previous escalating backoff reduced retry pressure.

Useful? React with 👍 / 👎.