fix(VCPClawMail): prevent short-lived WS connections from resetting retry backoff

[infinite-vector]

问题

VCPClawMail 的 WebSocket 即达监听在连接短暂成功后快速断开（如 CONNACK 后 2~3 秒收到 1006）时，
会立即将 state.retries 归零，导致退避数组 [1s, 2s, 5s, 10s, 30s, 60s] 永远停留在首档。
五个邮箱账号使用完全相同的固定延迟，同步断线后形成锁相惊群式重连风暴。

修复内容

1. 移除 CONNACK 后立即清零 retries 的逻辑

   • 连接成功只记录 connectedAtMs 时间戳，不再认为握手 = 稳定。

2. 在断开回调中按 uptime 判断是否清零

   • 若连接存活 ≥ 20 秒（WS_STABLE_CONNECTION_MS），认为旧失败已过时，清零 retries。
   • 若连接仅存活数秒，保留累计失败次数，让退避正常推进。

3. 为重连延迟加入有限 jitter

   • 实际等待 = 原档位 × random(0.8, 1.0)，不超过原上限 60 秒。
   • 五个邮箱的重连时刻不再完全同步。

4. stopWsListeners 清除 connectedAtMs

   • 维护"非连接态无连接起点"不变量。

测试

• 本地 PM2 重启后五个邮箱均正常完成 CONNACK → AES → Heartbeat。
• 低频轮询 / 子邮箱自动投递 / 邮件 HTTP API 均未受影响。
• node --check 语法验证通过。

未解决

• 首个 1006 的远端根因（网易 WuKongIM / 会话残留）不在本次修复范围。
• SDK timeDiff 的 uint64 回绕仅为日志现象，不参与重连决策。

说来，由于难以对网易邮箱的连接逻辑进行完美匹配，本次修改只是尝试增加了鲁棒性。
以我的观感，似乎是如果node进程被同步占据了一段时间后，直接强制用pm2命令重启，会比较容易出现这个问题。而且，出现这个问题后，只是restart似乎没法解决，非要kill后再度启动才能解决（存疑）。

附带改动

• Plugin.js：我自己的某个插件开发，需要只读知识库，于是加了一行通用性质的代码，或许是可以merge的。这与本次 WebSocket 修复无逻辑依赖。