debt(harness): feature_list.json 里 110/290 个 feature 的 owner 为 null，且大多数非 null 值是与 registry.yaml 不同命名空间的 sprint 临时把手

> 来源：角色记分卡（#1132）下一格设计阶段的实测发现，见
> `docs/proposals/PROP-ROLE-SCORECARD-WORKER-TIER-001.md`（#1141）。
> coord-main 2026-08-13 裁决：独立于评分卡，本身也该做，开独立 issue 排期。

## 实测数据（2026-08-13，5 个 phase，290 个 feature 全量扫描）

| owner 形态 | 例子 | 数量 |
|---|---|---|
| **null** | — | **110 个（38%）** |
| sprint 期临时把手 | `w2-chat4` `w3-itv11` `w0-auth` `agent-f20f21` | 绝大多数 |
| **真·registry 角色 id** | `dev-project` `dev-org-admin` `coord-voice` `coord-deep-research` `coord-user-research` | **仅 13 个** |
| 裸 Directory ULID | `agt_01KZRABCZ99M2NGN20C7YWEASG` | 3 |

⇒ **`feature.owner` 与 `.harness/agents/registry.yaml` 的角色 id 是两个不同的命名空间**，
今天无法可靠地把一个 feature 映射到一个真实角色。

## 为什么这独立于评分卡也该修

- 110 个 feature（38%）**没有任何归属信息**——出了问题不知道该找谁
- 剩下的大多数用的是**sprint 期一次性把手**（`w2-chat4` 这类），sprint 结束后
这些把手本身就成了死链接——它们从来没打算长期存在
- 这与本仓已知的「静态痕迹 ≠ 动态事实」是同一类问题：owner 字段记录的是
**写入那一刻**谁在做，而不是**现在**谁负责

## 建议范围（不是本 issue 的执行方案，只是起点）

1. **归一化**：把 sprint 临时把手映射到真实 `registry.yaml` 角色 id（需要人裁——
有些 sprint 已结束，可能查不到当时是谁）
2. **null 的显式化**：110 个 null 不是"待定"，应该在 feature_list.json 或派生视图里
显式标成 `unowned`，而不是留空
3. **机械门**：新增 feature 的 owner 必须 ∈ `registry.yaml` ∪ `.harness/agents/*.yaml`，
否则 `harness doctor` 判红——防止这个问题在归一化之后又重新长出来

⚠ **明确不建议**按前缀猜owner（比如 `w2-chat4` → `coord-chat`）——猜出来的归属
会产生一个看起来精确、其实编造的记录，比留空更糟。宁可先如实标成 `unowned`。

## 与其他工作的关系

- **角色记分卡（#1132/#1141）下一格（worker/domain agent 打分）在等这个**：
没有可靠的 owner 映射，`feature` 类可评项就是假的
- **与 #1136（完成定义可被绕过）独立**：那条是「status 能不能被伪造」，
这条是「owner 字段本身有没有意义」，两个不同的洞

Read feature_list.json, .harness/agents/registry.yaml, and docs/proposals/PROP-ROLE-SCORECARD-WORKER-TIER-001.md, then locate the harness doctor entry point. Define how existing temporary handles and null owners are represented without guessing, and verify that new owners are checked against the registry or agent YAML files.

Written by the indexing model from the issue text.