feat: bootstrap official runner through SPIFFE facade

docs/design-principles.md

@@ -94,4 +94,5 @@ OpenBao 或其他资源的特殊权限。资源所有者在资源端按照有意
 基础设施协议优先使用上游维护的成熟客户端，不在 controller 内重复实现认证、连接、
 资源编码或错误语义。Kubernetes 使用 `client-go`，NATS JetStream 使用 `nats.go`，
 Gitea RunnerService 使用 `actionslib`，OpenSandbox Lifecycle API 使用官方 Go SDK；
-自定义代码只保留领域模型、reconcile 规则及上游客户端未覆盖的最小适配层。
+SPIFFE Workload API 与 mTLS 使用 `go-spiffe`。自定义代码只保留领域模型、reconcile
+规则及上游客户端未覆盖的最小适配层。

docs/runner-protocol-roadmap.md

@@ -28,6 +28,13 @@ controller 暴露兼容 RunnerService 的 facade：`FetchTask` 只返回已分
 ID，以及由 controller 密钥确定性生成的 assignment HMAC capability；该 capability
 只绑定执行实例，不参与 Zot/OpenBao 等业务授权。
 
+executor 为官方 runner 生成与 v3.5.0 schema 一致的一次性 `.runner` 文件，并以
+`daemon --once` 启动。runner 只访问 executor 内的 loopback HTTP proxy；proxy 使用
+`go-spiffe` 从 Workload API 持续取得和轮换 X509-SVID，再以 mTLS 连接 controller
+facade，并严格校验 facade 的 SPIFFE ID。这样无需修改 runner 或把静态客户端证书写入
+镜像。assignment capability 会进入一次性 executor 环境，但不会进入 label、annotation
+或 OpenSandbox metadata；它只对该 assignment 有效，并且不能绕过 SPIFFE 身份校验。
+
 这与“收到 webhook 后临时注册另一个 act_runner”不同。`FetchTask` 已经完成任务分配，
 不能再期待 Gitea 把同一个 task 分配给随后启动的 runner。协议调度器必须让 executor
 执行已经领取的 task，并继续完成日志、状态、心跳、取消和最终结果上报。
@@ -67,6 +74,8 @@ ID，以及由 controller 密钥确定性生成的 assignment HMAC capability；
 - consumer 在 executor 使用上述 facade 成功 claim task 后确认 assignment；无需把完整
   task 写入 Pod annotation、OpenSandbox metadata 或环境变量。
 - Pod 与 VM 共享 task/executor 协议，只有环境创建和销毁实现不同。
+- 两种 backend 都注入同一份 runner bootstrap 环境；Pod 仍由 homelab Kubernetes 原生
+  创建，只有 VM 经 OpenSandbox 创建，bootstrap 机制不改变 backend 边界。
 
 ## 实现顺序