[Bug] LocalSubprocessRuntime.spawn() 未透传 WindowsJobInternals / LinuxScopeInternals，导致 runner 启动 seam 在生产路径不可达

[boyingliu01]

现象

windows-job.ts 与 linux-scope.ts 都把 runnerInvocation 声明为显式的可替换 seam，
但 LocalSubprocessRuntime.spawn() 调用这两个函数时没有传 internals，
于是这些 seam 在生产路径上恒不可达——只有直接调用 launchWindowsJob(spec, env, internals)
的单元测试才能碰到。
这不是新问题，是 #11893 描述现象在重构后的同构剩余：
缺陷从 spawn() 里的三元表达式，原样搬到了 spawn() 里 launch 的选择处。

证据

Windows 侧 —— packages/subprocess/subprocess-local/src/windows-job.ts:29-38

/** Test seams for runner launch and dynamic capability checks. */
export interface WindowsJobInternals {
  spawn?: typeof spawn
  runnerInvocation?: RunnerInvocation          // ← 声明的 seam
  resolveRunnerInvocation?: () => RunnerInvocation
  runnerAvailable?: (invocation: RunnerInvocation) => boolean
  loadWin32ProcessBindings?: typeof loadWin32ProcessBindings
  probeCurrentTokenJobSupport?: typeof probeCurrentTokenJobSupport
}

windows-job.ts:126-130 确实消费了它：

export function launchWindowsJob(
  spec: SubprocessSpawnSpec,
  targetEnv: Record<string, string>,
  internals: WindowsJobInternals = {},      // ← 默认空对象
): ManagedProcessLaunch {
  const invocation = internals.runnerInvocation ?? spawnRunnerInvocation()

但调用点 —— index.ts:206-210：

const launch = linuxScope === undefined
  ? launchWindowsJob(spec, env)                                      // ← 第三参数缺省 = {}
  : launchLinuxScope(spec, env, linuxScope.literalArgv)              // ← 第三位是 literalArgv
handle = bindManagedProcess(spec, launch, binding)

spawn() 已经算好了一份 internals（index.ts:202），但只喂给了 fallback 分支的
spawnSubprocess(spec, internals)，没有喂给 launchWindowsJob / launchLinuxScope。
Linux 侧更明显：launchLinuxScope 的签名是

// linux-scope.ts:672-677
export function launchLinuxScope(
  spec: SubprocessSpawnSpec,
  targetEnv: Record<string, string>,
  literalArgv: LiteralArgvOptions,
  internals: LinuxScopeInternals = {},      // ← 现在是第四位
): ManagedProcessLaunch {
  const invocation = internals.runnerInvocation ?? spawnRunnerInvocation()

internals 被挤到了第四位，而调用点只传三个参数。
LinuxScopeInternals（linux-scope.ts:33-43）里同样声明了
runnerInvocation / resolveRunnerInvocation / runnerAvailable，一个都到不了。

影响

1. internals 上塞任何东西都不生效。 LocalSubprocessRuntime.internals（index.ts:72）
   是公开字段，但在 Windows / Linux-scope 主路径上，写进去的 runnerInvocation 被静默忽略。
   只有 containmentMode === 'fallback' 时才会被消费。
2. 失败是静默的。 没有任何警告、没有类型错误（参数可选、有默认值），
   调用方会误以为自己成功替换了 runner，实际仍在跑默认实现。
3. 测试 seam 与生产路径不一致。 单测直接调 launchWindowsJob(spec, env, { runnerInvocation })
   能拿到自定义 runner，同一条代码路径走 spawn() 就拿不到。这类"测了但没测到生产路径"的
   偏差，恰恰是 seam 类接口最容易出的事故。
4. 阻塞了所有想替换 runner 的实现。 更换 runner 是实现层面的合法需求
   （例如用原生二进制替换 Node runner 以消除进程启动开销），而项目已为此准备好 seam，
   却无法从公开入口接上。

期望行为

spawn() 把已经构造好的 internals 透传给两个 launch*：

const launch = linuxScope === undefined
  ? launchWindowsJob(spec, env, internals)
  : launchLinuxScope(spec, env, linuxScope.literalArgv, internals)

若担心 SpawnInternals 与 WindowsJobInternals / LinuxScopeInternals 类型不兼容，
只需在调用处做一次窄化（这些字段本就是可选的，SpawnInternals 里没有的字段传 undefined 即可）。

为什么建议优先处理

• 修复面极小：一个调用点加一个参数，无控制流改动。
• 不需要社区代码：这是让仓库已有的 seam 真正可达，不涉及接受外部实现。
• 与项目自身设计意图一致：WindowsJobInternals 的文档注释写的是
  "Test seams for runner launch and dynamic capability checks"，
  说明"runner 启动方式可替换"是被有意设计的；当前只是没接到生产路径上。
• 顺手可加一条回归：构造一个 spawn() 级的测试，断言自定义 runnerInvocation 被调用到。
  这类测试能在未来再次重构时自动兜住同样的问题。

环境

• 仓库 main @ fcc0ad462172522aaf5c93a7b2e01f6b9f0b0159
• 相关问题在 0.2.0-rc.2 已存在（lib/index.js:1368），重构后位置改变、性质未变
• 平台：Windows（同理适用于 Linux-scope 分支）

---

附：备选措辞（若维护者偏好提 PR）

如果需要，本问题也可以只以 Issue 形式跟踪，由维护者自行修复——
提出方不需要提交任何代码。上文"期望行为"已给出最小 patch 形态。

[boyingliu01]

关联 #11893

[aturzone]

分析成立，已按同一处修复（LocalSubprocessRuntime.internals 的 runner seam 现在会真正进入生产 launch 路径）：

分支：https://github.com/aturzone/deepseek-harness/tree/fix/subprocess-managed-internals（commit ab42e3b983）

根因确认（packages/subprocess/subprocess-local/src/index.ts）：spawn() 在 202 行构造了一份 internals，但只用给了 containmentMode === 'fallback' 的 spawnSubprocess(spec, internals)；managed 分支的两行调用仍是 launchWindowsJob(spec, env) / launchLinuxScope(spec, env, linuxScope.literalArgv)，第三/第四个 internals 参数走默认 {}。所以 WindowsJobInternals.runnerInvocation / LinuxScopeInternals.runnerInvocation 等 seam 在生产路径恒不可达，且失败是静默的（参数可选、无类型错误）。

改动

• 新增 LocalSubprocessInternals = SpawnInternals & Pick<WindowsJobInternals, 'runnerInvocation' | 'resolveRunnerInvocation' | 'runnerAvailable'> & Pick<LinuxScopeInternals, 同三项>；internals 字段与 spawn() 局部变量改用该类型（仍兼容原有 SpawnInternals 用法）。
• 新增 managedRunnerSeams()：只把存在的三个 seam 放进对象（exactOptionalPropertyTypes 下不塞 undefined），再传给 launchWindowsJob(spec, env, seams) 与 launchLinuxScope(spec, env, literalArgv, seams)。
• 未把 spawn/systemctl/spawnSync/unixSocketTable 等平台内部字段一并透传：它们不是本次报告证明的 seam，扩大公开 internals 类型会引入 spawn 签名冲突；如果维护者希望完整 interning，可作为后续单独改动。

证据

• 修改既有 isolated-runtime 生产路径测试：linuxRuntime.internals 与 windowsRuntime.internals 注入三个 seam，断言 launchLinuxScope 的第 4 个参数、launchWindowsJob 的第 3 个参数收到全部 seam；把调用点临时还原后该测试失败（expected last "vi.fn()" call to have been called with [ Anything, Anything, [], { …(1) } ]），恢复后通过。
• subprocess-local 包测试 341 passed（排除本机两个已知环境失败：shell-activity 的 bash PS0 时序、spawn-runner 依赖宿主 NoDefaultCurrentDirectoryInExePath 的测试；两者在 master 上也同样失败）。
• pnpm run typecheck 5/5；full lint 0 errors。仓库 PR 通道关闭，分支供 cherry-pick。

另：这条与 #11893 是同一类「seam 只在单测可达」的残留，修复点也覆盖 #11893 描述的 runner 选择路径。