[Bug] 进入独立 worktree 后，forge 面板仍显示上一个检出里的变更请求

[choleraehyq]

[Bug] 进入独立 worktree 后，forge 面板仍显示上一个检出里的变更请求

现象

Session 在某个检出里发现了变更请求（下称 CR），面板正确显示。之后 Session 切到一个独立的 worktree（git worktree add 出来的链接检出）里工作，面板仍然显示上一个检出里那个 CR，并且不会发现 worktree 当前分支对应的 CR。

也就是说，面板显示的 CR 属于另一个检出，而不是 Session 正在工作的这个。

两个补充事实：

• 重启 Session 无效。 绑定是写进 Session 日志的记录，恢复 Session 会重放它。
• 和 provider 无关。 涉及的代码全在共享包里，没有任何 provider 特定逻辑，GitHub provider 和第三方 provider 表现一致。

复现

1. 在一个仓库里工作，当前分支有打开的 CR，让面板发现它。此时面板显示这个 CR。
2. 为 Session 创建 worktree，Session 转到一个不同分支的链接检出。
3. 看面板：仍是第 1 步那个 CR。既不会换成 worktree 分支的 CR，也不会把旧的去掉。

原因

三个互相独立的行为叠加。

1. 绑定没有检出维度，且永不删除

绑定是 Session 记录，折叠后的状态只有三个字段，不含"在哪里发现的"这一信息：projection.ts#L37-L41

const bindingsSchema: z.ZodType<readonly BindingState[]> = z.array(z.object({
  url: z.string(),
  origin: z.enum(['created', 'referenced', 'discovered', 'tracked']),
  dismissed: z.boolean(),
}).strict())

绑定记录的折叠只能追加绑定或翻转 dismissed，没有任何 action 能删掉一个绑定：projection.ts#L117-L140

因此 changeRequests(session) 返回的是这个 Session 历史上绑定过的全部 CR，与它当前在哪个检出无关：index.ts#L76

2. 面板把绑定原样发布，不做过滤

面板把 Session 的绑定逐个映射出去，entries() 不查当前检出、也不查仓库：panel.ts#L92、panel.ts#L210-L215

所以 Session 早先绑过什么，就一直留在界面上。

3. 新建 worktree 的分支没有 upstream，发现被跳过

面板只在检出配了 upstream 分支时才发起发现：panel.ts#L298

if (upstream !== null) this.discover(upstream)

upstreamOf 在没有配置 upstream 时返回 null：panel.ts#L302-L306

而 worktree 服务是用 worktree add -b 建检出的，不会给新分支配 upstream：worktree/src/index.ts#L194

await run(repositoryRoot, ['--work-tree', repositoryRoot, 'worktree', 'add', '--no-checkout', '-b', branch, '--', path, baseCommit])

于是新分支没有 upstream → upstreamOf 返回 null → 对 worktree 的分支根本不会调用 discover，没有任何东西替换掉从上一个检出继承来的绑定。

叠加结果

• 第一个检出里发现的 CR 永远不会被解绑，Session 进入 worktree 后它还在。
• worktree 的分支没有 upstream，不会触发发现，面板也就没有"当前的"内容可显示。

用户看到的是上一个检出的 CR，且没有任何办法让面板反映自己真正在工作的检出。

一个容易误判的点

面板确实会响应目录变化，它显示的检出信息（目录、分支、本地改动）会更新：panel.ts#L140-L143

observe(event: SessionEvent): void {
  if (event.type === 'working-directory/change') {
    this.publish({ ...this.current, directory: event.data.cwd, checkout: { state: 'pending' }, local: null })
    void this.inspect()
  }

inspectOnce 随后会重新检查新目录，重算 repository、upstream、local：panel.ts#L262-L299

缺口恰好在于：重新检查重算了检出事实，但从不协调绑定列表。而 forge-session 完全不知道目录变化——working-directory 这个字符串在 packages/experimental/forge-session/src/ 里一次都没出现。

两个服务对"当前检出是什么"的认知不一致：client-ui-forge 跟踪它，forge-session 不跟踪，而绑定归后者所有。

建议方向

值得保留的区分是：用户主动要的绑定 vs 工具推断出来的绑定。

• origin: 'tracked'：用户显式绑定的 CR，应该在检出变化后继续保留（现在是这个行为）。
• origin: 'discovered'：工具根据 Session 当时所在分支推断出来的，它的意义只相对于产生它的那个检出。

两种实现路径，改动量递增：

A. 在 discovered 绑定上记录检出。 给 discover 的记录加上检出（或仅加仓库），面板只显示属于当前检出的 discovered 绑定；tracked 绑定不过滤。好处是 Session 日志自描述，不需要跨服务通知。

B. 在目录变化时协调。 让 forge-session 感知 working-directory/change，检出变化时丢弃或重新推导 discovered 绑定。更符合"discovered 即当前"的语义，但给 forge-session 引入了对目录事件的新依赖，且仍需定义"Session 回到原检出时怎么办"。

无论选哪条，后半部分都是独立且值得单独修的：没有 upstream 的 worktree 分支也应该能发现它的 CR。可选做法是让 worktree 服务配置 upstream，或者让面板在无 upstream 时回退到本地分支名。否则即使绑定列表修对了，worktree 依然没内容可显示。

影响范围

• 涉及包：client-ui-forge、forge-session、worktree。
• 非 provider 特定：forge-github 和任何第三方 provider 行为相同，因为上述逻辑全在共享包里。
• 无数据损坏：旧绑定是显示问题，不是数据损坏。手动 dismiss 可以暂时隐藏，但底层记录仍在日志里，且下一个被发现的绑定会有同样的问题。

---

改动范围：forge-session（记录/折叠 + 可能的事件订阅）、client-ui-forge（发布时过滤）、worktree（upstream 配置）。按 CONTRIBUTING，我没有直接提 PR，先在这里报告。