fix: recognize ret=-2 as stale-session signal in Weixin adapter (#17228)

[vominh1919]

Problem

The Weixin adapter's session-expired fallback only recognizes errcode=-14 as a stale-session signal. In practice, iLink also returns ret=-2 with errmsg="unknown error" for the same underlying condition — typically when a cron job tries to push a message to a chat that hasn't had user activity for many hours.

The adapter treats ret=-2 as a rate-limit, exhausting retries with the same stale context_token instead of refreshing the session. Cron deliveries silently fail on the Weixin leg.

Fix

Added _is_stale_session_ret() helper function that distinguishes ret=-2 with errmsg="unknown error" from genuine rate limits. Updated both the poll loop (_run_poll_loop) and _send_text_chunk to use the helper.

3 changes in gateway/platforms/weixin.py:

1. Added _is_stale_session_ret() helper (centralizes the dual-meaning logic)
2. Updated poll-loop stale-session check (line ~1257)
3. Updated _send_text_chunk stale-session check (lines ~1519-1522)

Before vs After

Scenario	Before	After
iLink ret=-2, errmsg="unknown error"	Treated as rate-limit, retries fail silently	Recognized as stale session, strips context_token and retries
iLink ret=-2, errmsg="freq limit"	Rate-limit backoff (correct)	Rate-limit backoff (unchanged)
iLink errcode=-14	Session expired pause (correct)	Session expired pause (unchanged)

Tests

No existing tests cover this specific behavior. The fix is minimal and follows the same pattern as the existing errcode=-14 handling.

Fixes #17228

[teknium1]

Merged via #17432 — your commit was cherry-picked onto current main with your authorship preserved (e9b96fd). Thanks for the precise helper + poll-loop fix! Also added a 7-case truth-table test on top. Closes #17228.