fix: 发送工具守卫区分「本进程不是桥接」与「桥接未启动」

[Nike163]

现象

在非桥接的 pi 进程里调用 send_image_to_wechat / send_file_to_wechat（常见场景：桥接跑在 tmux 的一个 pi 会话里，人又开了另一个 iTerm 窗口用 pi），会返回：

❌ 微信桥接未启动，请先在 TUI 执行 /wechat start

但桥接其实完全正常 —— session.lock 有活着的持锁进程、cursor.json 持续更新。于是排查方向被彻底带偏（会一直去查「桥接为什么没起来」）。

根因

guardSendToWechat 判断的 client / running 都是进程内局部状态，非桥接进程无从得知另一个进程里的桥接状况，只能落进 !running 分支，并被当成「未启动」。另外 !client 分支文案（「微信未登录」）在跨进程场景下同样会误导。

改动

命中 !client || !running 时先读 ~/.pi/agent/wechat-assistant/session.lock：

• 持锁进程仍存活且不是本进程 → 直接告知真正的持有者与投递办法：

  微信桥接运行在另一个 pi 进程（PID 18116，pi-wechat-18116-xxx），本会话无法直接发送。
  请在那个会话里调用本工具，或把指令投递给它，例如：
    tmux send-keys -t <目标会话> "用 send_image_to_wechat 工具把 <绝对路径> 发到微信"
    tmux send-keys -t <目标会话> Enter
  

• 确认本机没有其它活着的桥接 → 保持原有两条文案不变。

安全性

只有诊断信息变化，不新增任何能力或权限。唯一新增的系统调用是 process.kill(pid, 0)，只做进程存活探测、不发送任何信号；读的是本扩展自己的 state 目录下的锁文件。路径沙箱、lastWechatUser 校验等守卫逻辑一字未动。

验证

• node --experimental-strip-types --check src/index.ts 通过
• 本地实测：在一个 iTerm 的 pi 进程里调用发送工具（桥接在 tmux 的另一个 pi 进程）→ 复现原误报；打上本补丁后提示正确指出持锁 PID，按提示投递指令人工执行成功送达