refactor: separate workload class from placement driver

docs/runner-protocol-roadmap.md

@@ -3,9 +3,9 @@
 ## 目标
 
 长期形态不依赖 `workflow_job` webhook 发现工作。controller 本身作为 Gitea Runner
-协议客户端注册，并声明 `self-hosted`、`pod` 和 `vm` labels；单个 registration 内按总
-配置容量启动多个 `FetchTask` goroutine，再将 task 按 `runs-on` 交给 Pod 或 VM 的独立
-容量池，由一次性 Pod 或 microVM 执行。
+协议客户端注册，并声明 workload class 与 driver labels；单个 registration 内按总
+配置容量启动多个 `FetchTask` goroutine，再将 task 按 `runs-on` 交给 placement 对应的
+独立容量池，由一次性 Pod 或 microVM 执行。
 
 ```text
 Gitea RunnerService
@@ -13,14 +13,14 @@ Gitea RunnerService
         ▼
 dynamic-runner scheduler
         │ 已领取的 task + lease
-        ├── Pod executor
-        └── microVM executor
+        ├── container.kubernetes executor
+        └── vm.opensandbox executor
                 │ logs / state / result
                 └──────────────────────► Gitea
 ```
 
-controller 使用单一 Go 二进制；默认在同一进程启用 `scheduler`、`pod-worker` 和
-`vm-worker`，也可通过 `--components` 只启用其中一部分。组件是独立应用服务边界，
+controller 使用单一 Go 二进制；默认在同一进程启用 `scheduler`、`kubernetes-worker`
+和 `opensandbox-worker`，也可通过 `--components` 只启用其中一部分。组件是独立应用服务边界，
 共享进程不意味着共享后端状态或把 assignment 降级为内存 channel。
 
 首轮集成的 facade pending/claimed registry 与三个组件同进程。虽然二进制保留组件选择
@@ -47,10 +47,13 @@ facade，并严格校验 facade 的 SPIFFE ID。这样无需修改 runner 或把
 
 ## 设计约束
 
-- 对 workflow 的接口保持 `[self-hosted, pod]` 和 `[self-hosted, vm]` 不变。
+- 规范接口为 `[self-hosted, container, kubernetes]` 和
+  `[self-hosted, vm, opensandbox]`。旧 `pod`、`vm`、`vm-dev` 标签保留严格映射，不能与
+  冲突 class/driver 混用；显式 driver 不允许自动回退。
 - scheduler 使用单一 Gitea runner UUID/token 和一个 `Declare`，不为并发槽位重复注册；
   `POD_CAPACITY + VM_CAPACITY` 决定并发 `FetchTask` goroutine 数量。
-- task 领取并持久化后按 backend 进入独立 durable consumer；对应容量池已满时延迟 NAK，
+- task 领取并持久化后按 placement 进入独立 durable consumer；v2 subject 为
+  `<subject-base>.<workload-class>.<driver>`。对应容量池已满时延迟 NAK，
   assignment 保持 JetStream pending，且不得创建超出配置容量的 workload。
 - scheduler Declare 后使用 RunnerService 长轮询；一旦 FetchTask 返回已分配 task，在
   JetStream publish 成功前只重试该 assignment，不领取下一项。
@@ -66,7 +69,7 @@ facade，并严格校验 facade 的 SPIFFE ID。这样无需修改 runner 或把
 - JetStream 只持久化和投递 assignment，不保存 executor 生命周期状态。Pod labels/annotations
   与 OpenSandbox metadata 是后端运行状态的权威来源，Gitea 是 task 终态的权威来源。
 - assignment 使用版本化 envelope 保存完整 Gitea protobuf task，并从 workflow `runs-on`
-  严格选择 pod 或 vm subject；消费者解码后重新派生 backend 与身份，拒绝被篡改的冗余字段。
+  严格选择 workload class 与 driver；消费者解码后重新派生 placement 与身份，拒绝被篡改的冗余字段。
 - JetStream 的 message ID 等于稳定 assignment ID `gitea-task-<task-id>`，仅用于发布去重，
   不承担 executor 生命周期记录。
 - worker 按稳定 assignment ID reconcile 后端资源，进程内只保留并发控制等可丢弃状态；
@@ -76,7 +79,7 @@ facade，并严格校验 facade 的 SPIFFE ID。这样无需修改 runner 或把
 - executor 成功 claim 后 ACK assignment。Gitea 接受 terminal update 后，facade 在后端
   metadata 写入持久 terminal marker；backend reconciler 仅在执行环境也进入终态后清理，
   从而关闭进程重启窗口且避免删除尚未完成结果上报的环境。
-- pod 与 vm 使用独立 durable consumer、进程内 admission pool 和并发上限。consumer 只负责将 assignment
+- 每个 placement 使用独立 durable consumer、进程内 admission pool 和并发上限。consumer 只负责将 assignment
   幂等落到后端；executor 与身份恢复 metadata 持久化后立即 `DoubleAck`。尚未取得
   Pod UID 等短暂未就绪状态以及临时后端错误使用延迟 NAK。
 - admission pool 只保存可重建的并发状态：启动时从 Pod labels/annotations 或 OpenSandbox
@@ -86,10 +89,10 @@ facade，并严格校验 facade 的 SPIFFE ID。这样无需修改 runner 或把
 - consumer 在 executor 使用上述 facade 成功 claim task 后确认 assignment；无需把完整
   task 写入 Pod annotation、OpenSandbox metadata 或环境变量。
 - Pod 与 VM 共享 task/executor 协议，只有环境创建和销毁实现不同。
-- scheduler 在 assignment 持久化到 JetStream 后即可继续领取；Pod 与 VM 分别由 durable
+- scheduler 在 assignment 持久化到 JetStream 后即可继续领取；各 placement 分别由 durable
   consumer 的 capacity 限制并发，不共享全局执行槽位。未知后端故障由对应 consumer 的
   NAK/redelivery 收敛，不能阻塞另一种 backend。
-- 两种 backend 都注入同一份 runner bootstrap 环境；Pod 仍由 homelab Kubernetes 原生
+- 两种现有 driver 都注入同一份 runner bootstrap 环境；container 仍由 homelab Kubernetes 原生
   创建，只有 VM 经 OpenSandbox 创建，bootstrap 机制不改变 backend 边界。
 
 ## 实现顺序