fix(channel): quiet WeChat poll log noise with state-transition logging and exponential backoff

[piorpua]

Summary

WeChat uses HTTP long-polling to receive messages. When the upstream (ilink/bot/getupdates) is unavailable, the poll loop logged a warn on every attempt and retried on a tight 2s × 3 + 30s cadence forever. In production (level=info) this produced ~5 warn lines/minute per bound account, indefinitely — pure noise that also buried any real signal.

This PR makes the WeChat poll loop quiet and self-throttling, with no change to Telegram / DingTalk / Lark, no PluginStatus/UI change, and no new dependencies.

Problem

• Every transient failure logged at warn (production-visible), with no de-duplication or rate limiting.
• Retry cadence (2s × 3 then 30s, reset, repeat) was both noisy and wasteful, and never backed off further.

Changes

Two orthogonal levers, both scoped to crates/aionui-channel:

1. State-transition logging. The failure stream now logs only on transitions:
   • first failure → one warn ("WeChat poll started failing")
   • subsequent failures → debug only (invisible in production)
   • recovery → one info ("WeChat poll recovered", with the failure count)
   • normal success → silent (unchanged)
2. Exponential backoff. Replaces the 2s × 3 + 30s scheme with 2^n seconds capped at 10 minutes (2, 4, 8, 16, 32, 64, 128, 256, 512, 600, 600…). Retries are unbounded and self-healing — a single success resets the streak.

Both API-error (ret/errcode) and transport-error paths now share one failure counter, one backoff function, and one logging policy. The log-level decision (poll_log_action) and the backoff curve (backoff_delay) are extracted as pure functions for unit testing.

The now-unused constants WEIXIN_MAX_RETRIES, WEIXIN_RETRY_DELAY, and WEIXIN_BACKOFF_DELAY are removed; WEIXIN_MAX_BACKOFF (600s) is added.

Behavior (upstream down for 1 hour, single account)

	Before	After
Production logs (info)	~300 warn	2 (start warn + recover info)
Retry attempts	thousands	~a dozen
Recovery	automatic	automatic (≤10 min to notice)

Testing

• Unit tests for backoff_delay (exponential curve + 10-minute cap + overflow guard) and poll_log_action (all four transitions).
• cargo test -p aionui-channel --features weixin → 256 passed / 0 failed.
• cargo clippy -p aionui-channel --features weixin -- -D warnings and default-feature clippy both clean.
• Full pre-push gate (just push) passed.
• Verified against a real upstream outage in the dev environment: exactly one warn on start, followed by debug lines whose intervals matched the backoff curve (2 → 4 → 8 → 16 → 32 → 64 → 128 s); the old per-2s warn spam is gone.

Non-goals

• Telegram / DingTalk / Lark behavior is untouched (Telegram's separate silent-give-up + stale-status issue is noted but out of scope).
• No PluginStatus/UI change; the loop's fix is fully internal.

Logging compliance

New warn/info lines carry only the network/HTTP error string, numeric error codes, failure counts, and backoff seconds — no prompts, message bodies, tokens, or secrets.