微信前端应正确处理过期 bot_token，避免后台反复弹出登录二维码

[slowlyo]

问题概述

微信前端在已保存的 iLink bot token 过期后，可能会进入异常状态。

当前 frontends/wechatapp.py 在 getupdates 返回 errcode == -14、errmsg == session timeout 时，只清空 updates_buf，然后继续使用同一个已经失效的 bot_token 轮询。

如果该进程由启动脚本或守护进程拉起，还可能在缺少有效凭据时进入二维码登录流程，从后台进程反复打开二维码或图片窗口。

观察到的现象

• temp/wechatapp.log 持续输出：[getUpdates] err: -14 session timeout
• 进程仍然存活，守护进程会认为微信前端在线，但实际已经无法收发消息
• 后台启动缺少有效 token 时，可能触发 login_qr() 并打开二维码窗口

期望行为

• errcode == -14 应被视为认证失效，而不是普通 updates_buf/session 游标问题
• 认证失效时应清空 bot_token、ilink_bot_id、updates_buf，并让进程以非 0 状态退出
• run_loop 不应把认证失效吞进通用异常重试逻辑
• 二维码登录应只在交互式启动或显式参数下触发，例如 --login / --relogin
• 后台启动缺少凭据时应只写日志并退出，不应弹出 UI 窗口

建议修复

• 增加专门的 AuthExpired 异常路径
• getupdates 返回 -14 时清理本地 token 并抛出认证失效异常
• run_loop 对认证失效直接向外抛出
• main 入口中区分交互式登录和后台启动
• 缺少 token 的后台进程直接退出，并提示用户手动重新扫码

影响文件

• frontends/wechatapp.py

[slowlyo]

补充一个实际触发场景：我这边出现问题前，这个微信 bot 曾经操作绑定过其它 agent。

之后再启动当前 GenericAgent 的微信前端时，虽然本地仍有 token 文件，但 getupdates 持续返回 -14 session timeout，表现为进程存活、守护进程认为在线，但实际微信消息无法正常接入。

这个场景可能意味着 bot_token 会因为同一个微信 bot 被其它 agent/客户端重新绑定或接管而失效，因此前端需要把 -14 明确当作认证失效处理，而不是继续使用旧 token 重试。