feat: 为执行后端增加独立容量池

README.md

@@ -18,7 +18,8 @@ runs-on: [self-hosted, vm]
 目标 Go controller 组件：
 
 - `scheduler`：以常驻 Gitea RunnerService 身份直接领取 task，并把完整 assignment
-  持久化到 JetStream；同时提供仅允许 SPIFFE mTLS 的 RunnerService facade。
+  持久化到 JetStream；一个 registration 下按配置启动多个并发 `FetchTask` goroutine，
+  同时提供仅允许 SPIFFE mTLS 的 RunnerService facade。
 - `pod-worker`：直接在 homelab Kubernetes 创建一次性 Pod。
 - `vm-worker`：通过 OpenSandbox Lifecycle API 从 `ci-vm` Pool 创建 Kata microVM。
 - 三个组件默认在同一个 Go 进程启用。首轮集成期间不允许只启动 worker，因为 facade
@@ -37,8 +38,9 @@ runs-on: [self-hosted, vm]
   动态 Pod 或 VM 直接取得自己的 SPIFFE 身份。
 
 Pod 路径由 homelab 集群中的 `pod-worker` 直接创建 Kubernetes Pod。OpenSandbox 只用于
-VM/Kata workload；两个 backend 使用独立 durable consumer，任一执行层故障不会阻塞另一条
-部署。长期 RunnerService 协议路线见
+VM/Kata workload；两个 backend 使用独立 durable consumer 和独立容量池。assignment 根据
+`runs-on` 进入对应池，池满时留在 JetStream pending，不会创建超出容量的 workload；任一
+执行层故障不会阻塞另一条部署。长期 RunnerService 协议路线见
 [`docs/runner-protocol-roadmap.md`](docs/runner-protocol-roadmap.md)。
 
 ## 开发