feat(VM): 吃透 Chaos VM 程序结构层 —— 模块注册表 + collect 槽位表可静态导出

补上 VM_SPEC §5/§6 自己点出的缺口（"不是 VM 的问题, 而是模块系统 + 宿主调用序列"）。

新增 tools/tdc_program.py（程序结构分析器）:
  * closures / entries / 字面串折叠 / 边界感知的函数体切分
  * module_registry(): 识别顶层 "registry[id] = factory" 装配模式 -> 62 个模块工厂
  * call_graph / shared_bodies / find_strings / --func 导出自身指令

修掉两个真 bug:
  * tdc_disasm: RET_TRUE / THROW 未当终结符 -> 控制流穿过函数结尾线性走下去,
    把父函数续段误判给夹在中间的兄弟函数（@4940 曾误归 @4362, 实为 @4160）
  * tdc_lift: 终结符判定写死 opcode 数值 19/49 -> 改为按语义名

新增 tools/tdc_layout.py（静态导出 cd 槽位表）:
  装配链已完全厘清:
    顶层 = 62 个模块工厂的注册表（工厂形参 (module, exports, require)）
    -> 清单模块 arr[arr.length] = require(N)  <<< 这串 require 的顺序就是 cd 槽位序
    -> 分发模块按 .on/.reset/.get 分三数组
    -> 装配模块 r3='{"cd":[' + for(...) r3 += r8.get() + '],"sd":{...}'
  跨构建实测: core_js 的 require 串与线上构建的串**不同**（槽位序按构建随机化, 与 #31 一致）;
  语义对位已验证若干槽（userAgent->cd[3], href->cd[4], languages->cd[5] 命中）。

VM_SPEC 新增 §9 程序结构层（模块系统 / 入口 / collect 装配 / 为何决定 12）。
selftest 全绿。

tools/tdc_disasm.py

@@ -254,6 +254,10 @@ def disassemble_cfg(z: List[int], entry: int = 0, follow_closures: bool = True,
     op_jump_if = next((o for o, n in names.items() if n == "JUMP_IF_TRUE"), OP_JUMP_IF_TRUE)
     op_push_try = next((o for o, n in names.items() if n == "PUSH_TRY"), OP_PUSH_TRY)
     op_closure = next((o for o, n in names.items() if n == "CREATE_CLOSURE"), OP_CREATE_CLOSURE)
+    # 终结符: 返回/抛出之后**没有 fall-through**。
+    # 漏掉这一步会让控制流"穿过函数结尾"线性走下去, 把所有后续代码都算进当前子程序
+    # (实测会把父函数的初始化序列误判成子函数自己的代码)。
+    op_terminators = {o for o, n in names.items() if n in ("RET_TRUE", "THROW")}
 
     visited: Dict[int, dict] = {}
     work = [entry]
@@ -282,6 +286,8 @@ def disassemble_cfg(z: List[int], entry: int = 0, follow_closures: bool = True,
             # 操作数 [0] 是闭包体入口: 该段代码在闭包被调用时才执行, 但它是**代码**,
             # 必须作为遍历根加入, 否则大半个程序都算不到。
             work.append(z[pc + 1])
+        if op in op_terminators:            # RET_TRUE / THROW: 无 fall-through
+            continue
         work.append(nxt)
     return [visited[k] for k in sorted(visited)]