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

docs/runner-protocol-roadmap.md

@@ -3,8 +3,9 @@
 ## 目标
 
 长期形态不依赖 `workflow_job` webhook 发现工作。controller 本身作为 Gitea Runner
-协议客户端注册，并声明 `self-hosted`、`pod` 和 `vm` labels；它只在后端存在可用容量
-时领取 task，然后将该 task 交给一个一次性 Pod 或 microVM 执行。
+协议客户端注册，并声明 `self-hosted`、`pod` 和 `vm` labels；单个 registration 内按总
+配置容量启动多个 `FetchTask` goroutine，再将 task 按 `runs-on` 交给 Pod 或 VM 的独立
+容量池，由一次性 Pod 或 microVM 执行。
 
 ```text
 Gitea RunnerService
@@ -47,7 +48,10 @@ facade，并严格校验 facade 的 SPIFFE ID。这样无需修改 runner 或把
 ## 设计约束
 
 - 对 workflow 的接口保持 `[self-hosted, pod]` 和 `[self-hosted, vm]` 不变。
-- scheduler 在没有对应 backend 容量时不领取 task，避免本地形成不可控积压。
+- scheduler 使用单一 Gitea runner UUID/token 和一个 `Declare`，不为并发槽位重复注册；
+  `POD_CAPACITY + VM_CAPACITY` 决定并发 `FetchTask` goroutine 数量。
+- task 领取并持久化后按 backend 进入独立 durable consumer；对应容量池已满时延迟 NAK，
+  assignment 保持 JetStream pending，且不得创建超出配置容量的 workload。
 - scheduler Declare 后使用 RunnerService 长轮询；一旦 FetchTask 返回已分配 task，在
   JetStream publish 成功前只重试该 assignment，不领取下一项。
 - 每个 executor 只执行一个 task，完成后销毁。
@@ -72,9 +76,11 @@ facade，并严格校验 facade 的 SPIFFE ID。这样无需修改 runner 或把
 - executor 成功 claim 后 ACK assignment。Gitea 接受 terminal update 后，facade 在后端
   metadata 写入持久 terminal marker；backend reconciler 仅在执行环境也进入终态后清理，
   从而关闭进程重启窗口且避免删除尚未完成结果上报的环境。
-- pod 与 vm 使用独立 durable consumer 和并发上限。consumer 只负责将 assignment
+- pod 与 vm 使用独立 durable consumer、进程内 admission pool 和并发上限。consumer 只负责将 assignment
   幂等落到后端；executor 与身份恢复 metadata 持久化后立即 `DoubleAck`。尚未取得
   Pod UID 等短暂未就绪状态以及临时后端错误使用延迟 NAK。
+- admission pool 只保存可重建的并发状态：启动时从 Pod labels/annotations 或 OpenSandbox
+  metadata 恢复非终态 assignment，terminal update 持久化成功后释放槽位，不引入新存储。
 - assignment ACK 后的运行、结果回报和清理由 backend reconciler 根据 Kubernetes、
   OpenSandbox 与 Gitea 的事实状态驱动，不继续占用 JetStream delivery。
 - consumer 在 executor 使用上述 facade 成功 claim task 后确认 assignment；无需把完整