chore(repo): promote the de-facto scope taxonomy into area/* labels

Issues and PRs currently have no area dimension. There is no way to filter, count, or route work by which part of the system it touches — the information exists, but only as free text in the title.

## Current state

Label usage across the 103 open issues:

| Label | Count |
|---|---|
| `enhancement` | 28 |
| `good first issue` | 7 |
| `bug` | 6 |
| **none** | **66** |

There are no `area/*`-style labels, no CODEOWNERS, and no milestones. The available labels are the GitHub defaults, which carry a type dimension (`bug` vs `enhancement`) but no notion of *where* in the system the work lives.

## The taxonomy already exists — it's just stored as a string

Classification is already being done by hand, on every issue, in the title. Conventional-commit scopes across the same 103 open issues:

```
runtime 12 · desktop 12 · headless 11 · test 6 · ui 4 · cloud 4 · e2e 3
windows 2 · benchmark 2 · workbar · scripts · runtime-host · release
providers · harness · core · computer-use · cli · browser · bash
```

So the effort is already being spent — it just doesn't produce anything queryable. 25 of the 103 have no prefix at all, which is where the convention breaks down entirely.

## Why it's noticeable now

I classified all 103 open issues while trying to work out which line of work my own contributions sit on. About 37 land under one of the three tracks in #544 (durable execution foundation, task/orchestration, benchmark-driven self-iteration). The remaining ~60% has no home — not because #544 is incomplete (durable-agent-platform is a coherent scope and this work is genuinely outside it), but because there is no index layer anywhere in the repo. That backlog isn't noise; it clusters cleanly:

| Cluster | Rough count | Examples |
|---|---|---|
| Desktop client experience | ~16 | #2084, #2188, #2317, #2359 |
| Engineering health (test perf, CI, refactor governance) | ~25 | #2382–#2390, #1084, #1404, #2207 |
| Platform & protocol compatibility (Windows, MCP, provider) | ~13 | #2142, #1650, #1383, #2330 |
| Cloud & multi-surface | ~6 | #1286, #2369, #2370, #2325 |
| Interaction modality | 2 | #1685, #1557 |

These counts are my own judgement call and some issues could reasonably go in more than one bucket — happy to publish the full per-issue mapping for review.

## Proposal

**a. Add `area/*` labels mirroring the workspace layout** — `area/runtime`, `area/runtime-host`, `area/desktop`, `area/ui`, `area/core`, `area/storage`, `area/headless`, `area/cli`, `area/mcp`, `area/computer-use`, plus two cross-cutting streams that don't map to a single package but clearly exist: `area/cloud` and `area/observability`.

**b. Auto-label PRs by changed path** via `actions/labeler` — fully automatic, no triage cost:

```yaml
# .github/labeler.yml
area/runtime: [ 'packages/runtime/**' ]
area/runtime-host: [ 'packages/runtime-host/**' ]
area/desktop: [ 'apps/desktop/**' ]
area/ui: [ 'packages/ui/**' ]
area/core: [ 'packages/core/**' ]
area/storage: [ 'packages/storage/**' ]
area/headless: [ 'packages/headless/**' ]
area/cli: [ 'packages/cli/**' ]
area/mcp: [ 'packages/mcp/**' ]
area/computer-use: [ 'packages/computer-use/**' ]
```

**c. Label issues at creation via an issue form.** Path-based labeling cannot work for issues — there are no changed files. The equivalent is `.github/ISSUE_TEMPLATE/*.yml` with an Area dropdown mapping to the same labels. There is no `ISSUE_TEMPLATE` directory today, so this would be new.

**d. One `rfc` label.** At least six open RFCs (#1382, #1625, #1650, #1679, #1685, #2290) are distinguished only by an `[RFC]` title prefix, and #544 / #2142 use a `roadmap:` prefix. A label would make both findable.

Backfilling the existing 103 issues is manual, but it is a one-time pass and the scope prefixes make most of it mechanical.

## What this deliberately does not propose

Not SIG/KEP-scale process — the repo isn't at that size and it would cost more than it returns. No milestones and no priority labels either: both need sustained maintainer attention to stay accurate, and a stale priority label is worse than no label. Just the one dimension that is already being maintained by hand.

## Offer

I don't have triage rights, so I can't create labels or apply them. If this is worth doing, I can open a PR with the `labeler.yml` workflow and the issue form, and leave label creation and the backfill pass to whoever has the permissions. Happy to drop any part of this that isn't wanted.

Related: #544

中文版本

目前 issue 和 PR 没有领域维度，无法按"改动涉及系统的哪一部分"来筛选、统计或分流 —— 信息是存在的，但只以自由文本的形式存在于标题里。

## 现状

103 个 open issue 的标签使用情况：`enhancement` 28、`good first issue` 7、`bug` 6、**无标签 66**。

没有 `area/*` 类标签，没有 CODEOWNERS，没有 milestone。现有标签是 GitHub 默认的那套，只有类型维度（bug / enhancement），没有"这活在系统的哪个位置"这个维度。

## 分类其实已经存在，只是存成了字符串

分类每次都在人工做，写在标题里。同样这 103 个 issue 的 conventional commit scope 频次：runtime 12、desktop 12、headless 11、test 6、ui 4、cloud 4、e2e 3、windows 2、benchmark 2，以及 workbar / scripts / runtime-host / release / providers / harness / core / computer-use / cli / browser / bash 各 1。

也就是说成本已经付出了，只是没有沉淀成可查询的东西。另有 25 个完全没有前缀，那是这套约定彻底失效的地方。

## 为什么现在会注意到

我在梳理自己的贡献落在哪条线上时，把 103 个 open issue 逐条归了类。大约 37 个能落进 #544 的三条主线（可持续执行底座 / 任务编排 / benchmark 自迭代），剩下约 60% 没有归属 —— 这不是说 #544 不完整，durable agent platform 本身是个自洽的范围，这些工作确实在它之外；而是仓库里没有任何索引层。这部分 backlog 不是杂音，能聚成清楚的几群：桌面客户端体验（约 16）、工程健康度（约 25）、平台与协议兼容（约 13）、云端与多端（约 6）、交互模态（2）。

这些数字是我个人的判断，有些 issue 放进两个桶都说得通 —— 需要的话我可以把完整的逐条归类清单发出来供 review。

## 提议

**a.** 加一组对应 workspace 结构的 `area/*` 标签，外加两个跨包但确实存在的工作流：`area/cloud` 和 `area/observability`。

**b.** 用 `actions/labeler` 按改动路径自动给 **PR** 打标签，全自动、零 triage 成本（配置见上方英文部分）。

**c.** issue 侧用 issue form 的 Area 下拉框。路径打标签对 issue 无效（没有改动文件），等价做法是 `.github/ISSUE_TEMPLATE/*.yml`。目前仓库没有 ISSUE_TEMPLATE 目录。

**d.** 加一个 `rfc` 标签。目前至少 6 个 open RFC（#1382、#1625、#1650、#1679、#1685、#2290）只靠标题的 `[RFC]` 前缀区分，#544 和 #2142 则用 `roadmap:` 前缀。

存量 103 个 issue 的回填需要人工，但只是一次性的，而且有 scope 前缀，大部分可以机械完成。

## 刻意不提议的部分

不提议 SIG / KEP 那种规模的流程 —— 仓库还没到那个体量，投入会大于收益。也不提议 milestone 和优先级标签：这两样都需要 maintainer 持续投入才能保持准确，而一个过期的优先级标签比没有标签更糟。只做这一个已经在人工维护的维度。

## 我能做的

我没有 triage 权限，建不了也打不了标签。如果这件事值得做，我可以提一个 PR 把 `labeler.yml` 工作流和 issue form 加上，标签创建和存量回填留给有权限的人。其中任何一部分不需要的话，去掉也没问题。

相关：#544

Start by inspecting the existing .github configuration and the packages/* and apps/desktop/* workspace paths described in the issue; there is currently no ISSUE_TEMPLATE directory. Define the path mappings in .github/labeler.yml and add the proposed issue form and labeler workflow, then verify that PR paths and issue Area choices map consistently; label creation and backfilling remain maintainer work.

Written by the indexing model from the issue text.