refactor(core): 拆分 Studio/Chat Manager 巨石为 Supervisor 架构

[ShuhaoZhangTony]

背景

当前启动与进程编排逻辑高度集中在 studio_manager.py（2332 行）与 chat_manager.py（1860 行），单类承担了进程管理、端口探测、日志、健康检查、模型切换、CLI 交互等多职责，导致可测试性和变更风险较高。

目标（对标 LumiStudio）

将“服务编排”收敛为可替换、可测试的 supervisor 架构，形成清晰的启动生命周期。

范围

• 拆分 StudioManager/ChatModeManager 为：
  • ProcessSupervisor（进程生命周期）
  • PortResolver（端口策略）
  • HealthMonitor（健康探测）
  • StartupReporter（统一状态面板输出）
• CLI 仅做参数解析与调度，不直接承载业务策略
• 保持现有 sage studio start/stop/status 对外行为兼容

验收标准

• studio_manager.py 与 chat_manager.py 任一文件 < 800 行
• 新增 supervisor 层单测（mock 进程 + 端口冲突场景）
• 启动输出仍符合当前统一格式规范（服务顺序/端口/日志路径对齐）
• sage studio status 与 restart 在 PID 漂移场景下行为可预测

证据

• 超大文件：studio_manager.py 2332 行，chat_manager.py 1860 行
• 全仓通用异常捕获较多（except Exception 155 处），与集中式巨石管理叠加放大风险

[ShuhaoZhangTony]

This issue is still valid, but the current assignment is only a repository-lead placeholder rather than accepted implementation ownership. I am removing that placeholder assignment and leaving the issue open for a domain owner.

The recommended owner profile and the complete audit are recorded in #31.

[ShuhaoZhangTony]

Current-main evidence: the public facade is small, but application/studio_manager.py is still 2,402 lines while the supervisor primitives cover only part of the lifecycle. The original < 800 lines acceptance criterion has not been met.

Recommended owner: Studio backend lifecycle and supervisor architecture.