[BUG][OPT-09] 保证 Studio 会话元数据与状态的原子更新删除 #193

总览：#180

代码依据

问题与范围

threads 与 threadStates 为两个 ConcurrentHashMap，创建、删除和更新跨 Map 顺序操作；例如 update 检查存在后，delete 删除两表，update 再写入 threadStates，可留下孤立状态。并发 delete/recreate 同一 ID 也需检查旧操作是否污染新会话。

验证状态：静态交错路径分析，尚未执行确定性并发复现。已有同 ID 并发创建测试，不等于覆盖跨 Map 原子性。

交付与验收

• 先使用 latch/barrier 等建立可重复的 create/delete、update/delete、delete/recreate 交错测试。
• 比较单 key 聚合记录与现有结构加锁等方案，保证同一会话元数据和状态一致；优先局部修复。
• 删除后不遗留状态，旧会话延迟更新不污染新会话；明确同 ID 重建的顺序语义。
• 读取、列表、重复创建拒绝、现有编码 key 的隔离行为回归。
• 不借修复强制引入数据库，也不改变 HTTP/公开 DTO；确需更改则单列迁移依据。

关联 #189 的状态读取边界，但本单仅解决 Studio 会话存储原子性。

变更约束

根据具体问题选择局部修复或设计调整。任何破坏性变更需比较兼容方案，说明收益、消费者影响、迁移成本、目标版本及验证方式；不为区别于上游而更改合理设计。