fix(gateway): retry Weixin prepare failures without token

[KoNit-K]

What does this PR do?

Weixin iLink can return ret=-2 or errcode=-2 with errmsg="prepare failed" after a peer context token has become stale. The adapter previously classified that response as a frequency limit, which opened its rate-limit circuit and prevented cron and notification delivery. This change recognizes prepare failed as the same stale-session response class as the existing unknown error variant, so the established tokenless retry path can deliver the message.

The narrow match still requires iLink's -2 code and the exact stale-session error text. Other -2 responses, including genuine frequency limits, retain the existing backoff and circuit-breaker behavior.

Related Issue

Fixes #112709

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• Regression coverage for an external provider response variant

Changes Made

• gateway/platforms/weixin.py — classify iLink ret or errcode -2 responses with errmsg="prepare failed" as stale sessions rather than rate limits.
• tests/gateway/test_weixin.py — parameterize the delivery regression across both response fields and assert that the retry drops the stored context token.
• tests/gateway/test_weixin.py — assert that the retry completes successfully without opening the rate-limit cooldown circuit.

How to Test

• scripts/run_tests.sh tests/gateway/test_weixin.py — 34 passed.
• ruff check gateway/platforms/weixin.py tests/gateway/test_weixin.py — all checks passed.
• The retained test_repeated_rate_limits_open_circuit_for_followup_sends control runs in the 34-test focused suite and confirms real frequency limits still open the circuit.

Evidence

• BEFORE RED: scripts/run_tests.sh tests/gateway/test_weixin.py -k prepare_failed_retries_without_context_token produced 2 failed cases on the pre-fix code, one for ret and one for errcode; each was reported as a rate-limit cooldown.
• AFTER GREEN: scripts/run_tests.sh tests/gateway/test_weixin.py completed with 34 passed and 0 failed after adding the stale-session variant.
• CONTROL: a -2 response with errmsg="frequency limit" remains outside the stale-session matcher, and the existing circuit-breaker regression remains green in the focused suite.
• Scope: the diff changes only the Weixin adapter and its focused gateway tests.
• CI lane classification: Python, Python product, scan, Docker, and Nix evaluate true for this Python production change; local Python verification is listed above. No Desktop, Rust, installer, or lockfile lane is opened.

Checklist

• I read the issue report and reproduced its response shape in a focused regression test.
• I tested both iLink response-field variants: ret=-2 and errcode=-2.
• I verified the first attempt keeps the context token and the retry sends without it.
• I verified a successful tokenless retry does not leave the rate-limit circuit open.
• I preserved the existing genuine frequency-limit control path.
• I ran the focused Python test command and recorded its pass count.
• I ran Ruff on both changed Python files.
• I checked the diff for whitespace errors and kept the change limited to two files.
• I rechecked for open PR competition for Weixin: iLink "prepare failed" misclassified as rate limit, breaking cron/notification delivery #112709 before pushing.
• I did not modify lockfiles, generated artifacts, or unrelated files.