chore: Align frontend with LexVoice gateway deploy

[jiejuncai-ly]

变更概述

这个 PR 让前端仓库只保留 Next.js UI 职责，并把 LiveAvatar sandbox gateway 的部署说明指向 LexVoice 仓库的 deploy/liveavatar_gateway。

主要改动

• README 说明 sandbox-backed public deployment 由 LexVoice 仓库负责。
• .env.example 不再承载 gateway/broker/template/warm pool/server-only secret 配置，改为指向 LexVoice 仓库下的 deploy/liveavatar_gateway/env.example。
• next.config.ts 的 allowedDevOrigins 只保留本地开发域名 liveavatar.local.lexmount.net，移除冗余生产域名。
• README 不再写死 ../lex-voice 或 lex-voice/... 路径，改为描述 LexVoice repository，避免隐含固定 workspace 布局。
• .gitignore 不再宽泛忽略顶层 /logs/，只保留旧 gateway 本地遗留 artifact 的精确忽略规则。
• 更新 tests/project-config.test.mjs，同步约束新的文档语义。

影响说明

• 前端运行时行为不变，仍由 LexVoice runtime 注入 LiveKit、room-input、agent、media 和 debug 相关环境。
• sandbox 创建、释放、warm pool 和 gateway 生命周期不在前端仓库维护，统一放到 LexVoice 仓库的 deploy/liveavatar_gateway。

验证

• pnpm test

  ✅ passed: 71 tests passed

• pnpm lint

  ✅ passed

• pnpm exec eslint .

  ✅ passed

• git diff --check

  ✅ passed

[jiejuncai-ly]

说明：allowedDevOrigins 只影响 Next.js development 模式下的跨域 origin 校验，不参与生产运行时配置。这里从 liveavatar.lexmount.cn 切到 liveavatar.local.lexmount.net 是为了匹配当前本地 gateway/dev 域名；如果本地 LexVoice 仍在使用旧域名，需要同步把本地访问域名更新到 .local 域名。

[github-actions]

Claude finished @jiejuncai-ly's task in 1m 35s —— View job

---

Todo List

• 读取 CLAUDE.md 和仓库约定
• 获取最新 PR diff (origin/lex-main...HEAD)
• 审查本次新增改动（重点核对 95b1d50 对上一轮 P2 的修复）
• 输出 Review 结论

Review 结论

通过

自上一轮 review 以来未发现新的代码变更（当前 HEAD 与上次审查时状态一致）。上一轮标记的两个 P2 已在 95b1d50 中修复并补充了测试：

• app/api/session/dispatch/route.ts:315-317：summarizeAgentParticipant 已移除 kind/attributes 字段，仅保留 identity；tests/session-start-dispatch.test.mjs 新增断言覆盖。
• components/livekit/agent-control-bar/track-device-select.tsx:110-112：已移除恒为 false 的无效 disabled={!open} prop。
• lib/session-stop-client.ts：gatewayReleasePath 相关函数参数由可选改为必传字符串，移除内部 resolveGatewaySessionReleasePath() 兜底调用，调用方在 beginAgentSessionStart/requestAgentSessionStop 处统一解析路径，逻辑更清晰；tests/session-stop-client.test.mjs 新增断言覆盖该约束。

其余改动（hooks/useBrowserSourceClient.ts 的 setAudioDeviceId、hooks/useRoom.ts 的 resolveVoiceSessionId、README/.env.example/.gitignore/next.config.ts 文档语义调整）与上一轮审查内容一致，未见新增问题：异常路径均有 try/catch 回滚，useCallback 依赖数组完整，文档未残留 lex-voice 硬路径或 secret。

问题及建议

未发现需要阻塞合并的问题。残余风险：app/api/session/dispatch/route.ts 中 dispatch 等待预算改动仍只有 source-regex 级测试，缺少真实超时/重试场景的行为级验证（非阻塞，可后续补充）。

[github-actions]

Claude finished @jiejuncai-ly's task in 3m 25s —— View job

---

Todo List

• 读取 CLAUDE.md 和仓库约定
• 获取最新 PR diff (origin/lex-main...HEAD)
• 审查自上次 review (95b1d50) 以来的新增改动 (6fb21d2)
• 输出 Review 结论

Review 结论

有条件通过

自上次 review 以来新增了 6fb21d2 Require room video readiness before reusing agent dispatch，将 pre-dispatch 的 agent 匹配逻辑抽到新文件 lib/session-dispatch-readiness.ts，并给"复用已加入 agent"路径新增了房间视频就绪校验。其余文件（README/.env.example/.gitignore/next.config.ts 等）与上次审查内容一致，未见新增问题。

问题及建议

• [P1] lib/session-dispatch-readiness.ts:22-31（被 app/api/session/dispatch/route.ts:161 调用）：findReusableAgentParticipant 现在要求 room_video_input 参与者已发布未静音的视频轨道，才认为已加入的 agent 可复用；但同文件中用于首次派单成功判定的 waitForAgentParticipant（route.ts:250-252）完全没有同样的校验。若某些会话场景下 room_video_input 迟迟未加入（网关桥接延迟）或从不出现（纯音频场景），alreadyJoined 会永远为 null，导致 createAgentDispatchWithRetry 的重试循环（route.ts:157-221）对已经在房间里的 agent 重复调用 dispatchClient.createDispatch，存在产生重复 agent 派单的风险。建议：a) 确认本产品是否所有会话都保证存在 room_video_input，如否需要给复用校验加超时/降级；b) 补充一个覆盖"agent 已加入但房间视频未就绪时重试是否会重复派单"的行为级测试，而不仅是当前 tests/session-dispatch-readiness.test.mjs 里的纯函数级断言。Fix this →

• [P2] lib/session-dispatch-readiness.ts:22-31 vs route.ts:186-192：初始派单成功路径与"复用"路径的就绪语义不一致——复用要求房间视频轨道就绪，首次派单成功却不要求。若意图是"agent 必须具备房间视频输入才算真正 ready"，首次路径存在同样的缺口；若该要求只服务于复用场景，建议加注释说明原因，避免后续维护者误解。

其余改动（README/.env.example/.gitignore/next.config.ts 文档语义调整，以及上一轮已确认修复的 summarizeAgentParticipant、track-device-select.tsx、session-stop-client.ts 改动）未发现新问题。

[github-actions]

Claude finished @jiejuncai-ly's task in 1m 44s —— View job

---

Todo List

• 读取 CLAUDE.md 和仓库约定
• 获取最新 PR diff (origin/lex-main...HEAD)
• 审查自上次 review (6fb21d2) 以来的新增改动 (d837d33)
• 输出 Review 结论

Review 结论

有条件通过

自上次 review 以来新增了 d837d33 Keep sandbox alive during page refresh：requestAgentSessionStop 新增 releaseGatewaySession 选项且默认为 false（原先默认总是释放 gateway sandbox），只有 agent-control-bar.tsx:125（用户主动点击结束会话）显式传入 { releaseGatewaySession: true }。

问题及建议

• [P1] hooks/useRoom.ts:154（recoverFromStartError 内的 requestAgentSessionStop 调用）：本次改动把 releaseGatewaySession 默认值从"总是释放"改为"默认不释放"，但该调用点未同步补上 releaseGatewaySession: true。此路径用于"已连接房间但会话启动失败"时的清理（connectedRoomName 已建立、可能已创建 sandbox），修改前会释放 gateway sandbox，现在会静默保留，导致启动失败场景下 sandbox 资源泄漏（不会被前端主动释放，需等 warm pool 超时兜底）。tests/session-start-dispatch.test.mjs:217-231 仅断言了 waitForRemote: true，未覆盖 releaseGatewaySession，未能捕获此回归。建议：确认是否需要为该调用补上 releaseGatewaySession: true（若启动失败时应释放 sandbox），并补充对应断言。Fix this →

• [P2] hooks/useRoom.ts:87-89（effect 卸载清理）：同样受默认值翻转影响，现在卸载时（含页面刷新、真正离开页面/关闭标签页两种场景）都不释放 gateway sandbox。对"页面刷新保活"是期望行为，但对"用户真正关闭标签页/离开页面"场景，sandbox 也不会被释放，只能依赖服务端 idle/warm pool 超时回收。建议确认这是否符合预期成本模型，非阻塞。

其余改动（lib/session-stop-client.ts 的 releaseGatewaySession option 实现、tests/session-stop-client.test.mjs 新增/调整的用例）逻辑清晰，测试覆盖了默认不释放、显式释放、超时、warn on non-2xx 等路径，未见新问题。上一轮已确认修复的 summarizeAgentParticipant、track-device-select.tsx、session-dispatch-readiness.ts（P1/P2 待跟进，见上一轮 review）等内容保持不变。

[github-actions]

Claude finished @jiejuncai-ly's task in 1m 54s —— View job

---

Todo List

• 读取 CLAUDE.md 和仓库约定
• 获取最新 PR diff (origin/lex-main...HEAD)
• 审查自上次 review (d837d33) 以来的新增改动 (cc916d1)
• 输出 Review 结论

Review 结论

通过

自上次 review 以来新增了 cc916d1 Stop releasing sandboxes from client session stops：彻底移除了 lib/session-stop-client.ts 中的 releaseGatewaySession 选项及 resolveGatewaySessionReleasePath/sendGatewaySessionRelease 相关逻辑，requestAgentSessionStop 不再从前端主动释放 gateway sandbox；agent-control-bar.tsx:125 同步改为 requestAgentSessionStop(sessionId)（不再传 releaseGatewaySession: true）。

这也一并解决了上一轮 review 中标记的两个问题：hooks/useRoom.ts:154（recoverFromStartError）和 hooks/useRoom.ts:87-89（卸载清理）不需要再补 releaseGatewaySession: true，因为该 option 已整体移除——release 职责完全收归 LexVoice/gateway 服务端，与 PR 描述的"sandbox 创建、释放、warm pool 和 gateway 生命周期不在前端仓库维护"一致，行为在所有调用点上统一。

问题及建议

• [P2] tests/session-stop-client.test.mjs:74-203：does not release gateway sandbox sessions by default on public paths、ignores public sandbox paths during local cleanup、background agent session stop does not release gateway sandbox sessions、skips gateway release outside public sandbox paths 这几个测试仍然设置 globalThis.window.location.pathname（如 /s/abc123/live），但 lib/session-stop-client.ts 已完全不引用 window/pathname（grep 确认无匹配），这些测试无论 pathname 取何值断言结果都相同。测试名称暗示仍存在"按路径决定是否释放 gateway"的分支逻辑，但代码中已不存在该分支，容易让后续维护者误判行为。建议：简化这几个测试、移除无效的 window mock，并将测试名改为反映"stop 请求不再触发任何 gateway release 网络调用"这一事实。非阻塞。

其余改动（README/.env.example/.gitignore/next.config.ts 文档语义、lib/session-dispatch-readiness.ts、app/api/session/dispatch/route.ts）与前几轮审查内容一致，未见新问题（上一轮 session-dispatch-readiness.ts 的 P1/P2 就绪语义不一致问题仍待作者确认是否需要处理，未在本次改动中涉及）。