debt(harness): sweep-docker 的孤儿判据只看 worktree 存在性 —— 「agent 已死、worktree 尚存」的栈对它完全隐形

## 实测：17 个栈在跑，工具报 0 孤儿

```
$ pnpm harness sweep-docker
巡检了 17 个 docker compose 栈：17 个对应的 worktree 仍存在，0 个是孤儿。
没有发现孤儿栈。
```

同一时刻，rev-uiux 在另一条会话里报告「14 个栈在跑，其中几个像是已结束会话的残留」——
它是对的，工具是错的。

## 盲区在哪

`sweep-docker` 的孤儿判据是「**这个栈的 compose 文件所在 worktree 还存在吗**」。
于是这种情况对它完全隐形：

> **拥有这个栈的 agent 已经死了，但它的 worktree 还在。**

具体到今天这次：`/private/tmp/wsx-660` 是一个 subagent 建的，该 subagent 后来被
`TaskStop` 杀掉（改用独立 session 托管 #660）。worktree 没删，于是它名下的 3 个栈
（`workspacex-kernel` + 2 个 `wsx-*`）永远被判定为"有主"。

**这正是 17 个栈能在「没有孤儿」的报告下堆积起来的机制**——而 2026-08-08 那次
load 66 → Docker daemon 崩溃的事故，根因就是栈堆积。工具当时大概率也报的是 0 孤儿。

## 为什么这不是「再加一条启发式」能修的

诱惑是加判据（比如"超过 N 小时未活动的栈算孤儿"）。**不要这么做**——本仓已有前车之鉴：
2026-08-08 有 agent 凭 config 路径匹配推断归属、拆了不属于自己的栈，被安全分类器拦下，
随后写进 `agent-resource-cleanup-sop.md` 的硬规矩是：
> 只清理**能证明是自己创建**的栈，不得基于路径/名称/健康状态等启发式推断归属。

启发式检测同样会误伤——一个跑了 6 小时的长任务栈和一个 6 小时的孤儿，从外部看一模一样。

## 可能的修法（待评估，不要直接开做）

方向是**让归属可证明，而不是可推断**：
- 起栈时把 owner 标识（session id / agent id）写进 compose 的 label
- 配一个心跳或 lease：owner 定期续期，过期即可判定为真孤儿
- `sweep-docker` 改为读 label + lease，而不是推断 worktree

代价与误报率要先估。**在有 owner 标签之前，工具的正确行为可能是如实报告
「我判不出归属」，而不是报 0 孤儿**——后者会让人以为清场过了。
（同 CLR 的 `null` vs `[]` 语义：问不到 ≠ 没问题。）

## 已做的处置
只拆了 2 个能证明属于自己的临时测试栈（逐个核对 `ConfigFiles`），栈数 17 → 15。
`workspacex-kernel`（共享持久栈、有活连接）与那个 worktree 都刻意保留——
删 worktree 会让共享栈的 compose 路径悬空，制造一个更难清理的真孤儿。

Start with the `sweep-docker` command and the ownership guidance in `agent-resource-cleanup-sop.md`; review how `ConfigFiles` is used to identify stacks. Compare the current worktree-based result with the reported 17 running stacks and determine what ownership evidence is available. Done means the ownership semantics and the cost of labels or leases are evaluated, with uncertain ownership no longer presented as zero orphan stacks.

Written by the indexing model from the issue text.