Quota guard pauses capture on seven_day_overage_included "rejected" even though the request succeeded (15.3.0)

## Summary On 15.3.0 with Claude subscription auth, the quota guard pauses capture whenever the `seven_day_overage_included` rate-limit window reports `status: "rejected"` — even though the request itself **succeeded** on the normal weekly allowance. Every cooldown probe then succeeds, stores an observation, and immediately re-arms a 30-minute cooldown, so capture stays paused until the overage-included window resets (days), while the account has plenty of normal allowance left. ## Environment - claude-mem 15.3.0 (worker on Linux, bun), Claude Code CLI v2.1.312 - `CLAUDE_MEM_PROVIDER=claude`, `CLAUDE_MEM_CLAUDE_AUTH_METHOD=cli` (Claude Code OAuth token, Max subscription) - Health endpoint rate limits at the time: `five_hour` 2%, `seven_day` 52%, `seven_day_overage_included` = rejected ## Evidence (worker log, one probe) ``` 12:39:13.126 [SDK] Starting SDK query {sessionDbId=279, ...} 12:39:18.998 [SDK] [session-279] ← Response received (1498 chars) {promptNumber=71} 12:39:19.004 [DB] [session-279] STORED | ... obsCount=1 | obsIds=[15033] 12:39:19.012 [SDK] Aborting session for quota guard: quota:seven_day_overage_included rejected by provider {window=seven_day_overage_included, ...} 12:39:19.780 [SESSION] [session-279] Generator paused for quota; preserving buffered work {pendingCount=76} ``` The same sequence repeated at 11:37, 12:08 and 12:39 — each probe got a real response and stored an observation, then the guard aborted and re-armed `quota-cooldown.json` (`until = armedAt + 30 min`). Between probes: ``` Skipping generator start while the provider cooldown is active {provider=claude, window=seven_day_overage_included, ...} Primary in quota cooldown and the quota fallback cannot serve; capture waits until it clears {primary=claude, fallback=claude} ``` SessionStart banner: *"The memory observer's allowance on claude is used up … Claude rejected the request because its weekly overage-included usage allowance is exhausted."* Changing `CLAUDE_MEM_MODEL` does not help (the cooldown is per provider and the next event re-arms it), and neither does a restart. ## Root cause In the bundled `worker-service.cjs` the hard-rejection branch (minified `OLe`) treats `status === "rejected"` on **any** window as exhaustion: ```js function OLe(t,e){ if (e.status==="rejected" || t==="overage" && e.overageStatus==="rejected") return {abort:!0, window:t, reason:`quota:${t} rejected by provider`, pause:{kind:"quota_exhausted", ...}} } ``` and `g7` includes `seven_day_overage_included` in the windows it walks. For that window, `"rejected"` only means the included-overage pool is spent — the request is still served from the normal allowance (as the stored observation proves). The `overage` window already gets special handling via `overageStatus`; `seven_day_overage_included` needs the same kind of exception. ## Workaround / suggested fix Local one-line patch (applied to both the marketplace and cache copies), then clear `~/.claude-mem/quota-cooldown.json` and restart the worker: ```diff -function OLe(t,e){if(e.status==="rejected"|| +function OLe(t,e){if(e.status==="rejected"&&t!=="seven_day_overage_included"|| ``` After the restart, capture resumed immediately (new observation stored, no guard abort, no cooldown re-armed). A more robust fix in source might be: only treat a window's `rejected` status as exhaustion when the request actually failed (no assistant response / an error result), or exclude informational windows like `seven_day_overage_included` from the hard-rejection branch while still letting the utilization thresholds apply. Related: #5012 (different stale-entry wedge; its "smaller related observation" about `overage`/`overageStatus` is the same family as this one).