任务：一份很小的提交让 submit_result 内部崩溃，修正说明也不够具体
真实运行（缺陷转用例，真实 Circle 客户端）里，一次只有约 2.4 KB 的提交连续两次让 Hub 返回内部错误（MCP -32603），管理员记录里只有一句 RangeError: Maximum call stack size exceeded，没有调用栈；出错的提交没有存下，客户端那边的会话目录也已经清掉，原文找不回来。同一轮里模型前七次提交都把 commands 的每一项写成了字符串，回执的修正说明只说“按槽位模式改正后重交”，模型就一直改不对。
- 分支和工作树：
hub-submit-robustness，目录circle-hub-submit-robustness（依赖已装好） - 可以改的路径：
hub/server/**（工具入口、错误处理和管理员记录）、hub/runs/**（提交的解析、证据收集、引用解析的调用处）、hub/refs/**（引用解析）、hub/records/**里的规范 JSON（如果递归在那里），以及对应的测试和tests/acceptance/**的一个场景。别的路径不动；改合约要先回报。 - 规则：同前（不推送、不建 PR、不发布、不部署，不碰 7420、钥匙串、环境配置文件和任何真实系统；测试只用合成数据；
git commit -s，合并用git merge --signoff）。
要做的
- 可诊断：任何工具调用落到“内部错误”时，管理员记录里写上错误的调用栈（只写栈帧的函数名和仓库内的相对位置，不写本机绝对路径，不写参数原文）。先写测试：人为抛错时记录里有栈。
- 找出并消除这次的递归。没有原文，所以从
submit_result能走到的每个递归处入手，逐个写合成的复现测试：- 很深的嵌套（2.4 KB 里能塞一千多层数组或对象）经过参数校验、规范 JSON 和证据收集；
- 引用之间成环：提交里引用本次运行自己先前的验证结果（
rec:），那份结果又引用这份提交；或一个片段引用指回它自己； - 别的你在代码里看到的、没有访问集合或深度上限的递归。
能复现栈溢出的那个就是这次的缺陷，修好；其余的也一并加上限。
- 统一的处理：JSON 的嵌套深度超过上限（例如 64 层）时，整份提交不受理，码用已有的提交结构错误，修正说明写“嵌套超过 N 层”；引用解析带访问集合，碰到环停下来，这一处记为引用解析不出，修正说明写明成环的引用。绝不落到内部错误。
- 修正说明具体化：提交的结构错误按出错位置在槽位模式里的定义给出要求的形状。例如“
/items/0/slots/cases/0/commands/0要的是对象{"command": "<命令行>", "present"?: 布尔}，收到的是字符串”。只用槽位模式里已有的信息，不写包的名字。 - 测试先写，验收场景加一例（深嵌套和引用成环各被拒，回执里有修正说明，没有内部错误）。验证：
npx tsc --noEmit；node --test --test-concurrency=3对改过的路径和新场景（数据库测试别和别的终端同时跑）。
完成后在终端里回报：提交号、测试数量、找到的递归在哪里、没做完或拿不准的地方。