v0.18.0

Bug Fixes

• sticky pool failover: there is no longer a "main" account. The pool stays on whichever member is currently active until that member itself exhausts, then advances forward to the next member and stays there. A lower-position member recovering from cooldown no longer causes a switch back to it. Previously a position-0 member with an exhausted upstream quota would be re-probed every 60s (when its short rate-limit cooldown lapsed), 429 again, and fail over again, producing an endless stream of identical "failed over" Telegram notices while the agent kept working on the other account. A failover, and its single audit event and Telegram notice, now happens only on a genuine exhaustion transition #48 @nnemirovsky

Improvements

• the sticky current-active selection lives on the swap-surviving shared pool health state, is epoch-scoped so a removed-and-recreated pool with overlapping member names cannot inherit a stale hold, and uses a read-mostly fast path so the per-request resolve no longer serializes on a write lock. The all-cooling degrade behavior and the audit Reason and pool_exhausted formats are unchanged. A selectable position-vs-sticky strategy mode is a possible follow-up #48 @nnemirovsky