fix: 隔离 Pod 与 VM 并发容量

docs/runner-protocol-roadmap.md

@@ -80,9 +80,9 @@ facade，并严格校验 facade 的 SPIFFE ID。这样无需修改 runner 或把
 - consumer 在 executor 使用上述 facade 成功 claim task 后确认 assignment；无需把完整
   task 写入 Pod annotation、OpenSandbox metadata 或环境变量。
 - Pod 与 VM 共享 task/executor 协议，只有环境创建和销毁实现不同。
-- 首次生产 canary 使用 controller 进程内 single-flight gate：只有官方 runner 的终态
-  `UpdateTask` 已被 Gitea 接受后才允许 Fetch 下一条任务。它把未知故障收敛为停止领取，
-  而不是在 backlog 下连续创建 executor；后续容量调度必须以 backend 实际运行资源为准。
+- scheduler 在 assignment 持久化到 JetStream 后即可继续领取；Pod 与 VM 分别由 durable
+  consumer 的 capacity 限制并发，不共享全局执行槽位。未知后端故障由对应 consumer 的
+  NAK/redelivery 收敛，不能阻塞另一种 backend。
 - 两种 backend 都注入同一份 runner bootstrap 环境；Pod 仍由 homelab Kubernetes 原生
   创建，只有 VM 经 OpenSandbox 创建，bootstrap 机制不改变 backend 边界。