[Bug] WeChat iLink: one-time context_token consumed by typing indicator -> replies rejected (ret=-2), 'working' indicator stuck

# [Bug] WeChat iLink: one-time `context_token` is consumed by the typing indicator, so replies are rejected (ret=-2) and the "working" indicator gets stuck

## Summary

On the WeChat (iLink) channel, the one-time `context_token` is used for **both**
(1) starting the "typing" indicator and (2) sending the reply. The typing call
consumes the token, so the reply is rejected with `ret=-2`
("context_token is invalid/consumed"). Additionally, the "cancel typing"
signal occasionally fails to send, leaving the indicator permanently shown
(the user sees the bot "working" forever).

## Environment

- QwenPaw (latest, `qwenpaw app`)
- Channel: WeChat personal (iLink, base_url `ilinkai.weixin.qq.com`)

## Evidence (source)

`qwenpaw/app/channels/wechat/channel.py`:

- `send_text` marks `send_meta["_wechat_token_invalid"] = True` when `ret == -2`
and the code comment states: `# ret=-2 means context_token is invalid/consumed;`
→ **subsequent sends in the same request are skipped** (line ~1129-1132).
- The typing indicator is started with `client.sendtyping(user_id, ticket, status=1)`
and cancelled with `status=2`; the cancel path is wrapped in
`try/except: pass` and fires asynchronously — a failed cancel leaves the
indicator up indefinitely (no retry / timeout fallback).
- The channel keeps a per-user one-time `context_token` cache
(`self._user_context_tokens`) shared by both typing and sending.
- `message_merge_enabled` exists specifically to
"mitigate the 10-msg context_token limit" (line ~132) — confirming the
token is a scarce, one-time resource, yet typing also spends it.

## Observed behavior

- Every reply in our logs is preceded by `wechat send_text rejected: ret=-2`.
- Long replies are truncated or dropped entirely (all chunks after the first
failure are skipped).
- The "working/typing" indicator stays on after the task finishes, sometimes
permanently ("the bot looks like it is always working").

## Expected behavior

- Typing indicator and message sending should **not share / consume** the same
one-time `context_token` (or typing should use a separate token/ticket that
does not invalidate the send token).
- Cancel-typing should be retried or have a timeout fallback so the indicator
is always cleared.
- `message_merge_enabled` should perhaps default to `true` for WeChat to
reduce token pressure.

## Impact

- Users on WeChat lose part of replies / entire replies.
- Stuck "working" indicator confuses users and hides the real status.
- This is a framework bug (channel design), not a user misconfiguration.