fix(frontends): 修复桌面宠物端口占用问题

[fkeuwgqtllb20]

变更说明

修复桌面宠物在部分 Windows 环境下无法启动的问题。

问题原因

桌面宠物原先固定使用本地端口 51983 作为 HTTP 控制端口。
在部分 Windows 系统中，该端口可能落入系统排除端口范围，导致启动时报错：

PermissionError: [WinError 10013]

这会使桌面宠物进程直接退出，因此用户点击“🐱 桌面宠物”后看不到任何显示效果。

修复内容

• 将桌面宠物控制端口从固定端口改为自动选择可用端口
• 将当前实际使用的端口写入临时文件，供前端读取
• 修改 stapp.py，发送桌面宠物消息时不再写死 51983，而是读取当前端口
• 同时兼容：
  • frontends/desktop_pet.pyw
  • frontends/desktop_pet_v2.pyw

影响范围

本次修改仅影响桌面宠物功能，不影响主 Agent、LLM 调用链路或其他前端入口。

验证结果

已完成以下验证：

• 在本地复现桌面宠物因端口占用/系统保留端口导致启动失败的问题
• 修复后桌面宠物可正常启动
• 可成功监听动态分配端口
• 前端可通过读取端口文件向桌面宠物发送提示消息
• 主界面重启后功能可正常使用

相关文件

• frontends/desktop_pet.pyw
• frontends/desktop_pet_v2.pyw
• frontends/stapp.py

[lsdefine]

Thanks for the fix. I think this is a bit over-engineered for the problem we are solving.

The original issue is that on some Windows machines, ports in the 5xxxx range may fall into Hyper-V / system excluded port ranges, so binding to 51983 can fail. We have already taken that into account and switched the default port from 51983 to 41983, which is currently free and outside the usual dynamic/excluded range on affected setups.

Given that, I would prefer a much simpler fix:

• just change the default port
• avoid adding file-based port coordination
• avoid duplicating the same helper logic across multiple files

So I do not think the extra file + dynamic port management code is worth the added complexity here.