pnpm override 的 parent>child 选择器对 peerDependency 解析不可靠（已在 PR #2613 修过一次实例，需要更通用的加固）

## 更新：之前的分诊结论错了，这确实曾是 PR #2613 引入的真实回归（已修复）

本 issue 最初的说法是「红的不是这次改动引入的真实回归，是环境/时机相关的既有脆弱点」——这个结论是用错误的方法论得出的：我在验证时用「非 frozen 的 `pnpm install`」去代表 CI 实际用的 `pnpm install --frozen-lockfile`，这是两条不同的代码路径。`git diff origin/main -- pnpm-lock.yaml` 显示 PR #2613 自己提交的 lockfile 确实把 `@langchain/langgraph-checkpoint-postgres` 这条边从 `0.1.1` 改成了 `1.1.5`——main 的 committed lockfile 从始至终是对的，frozen 模式下不会重新触发那次错误的 resolve。详见 PR #2613 的撤回评论。

**这一具体实例已在 PR #2613 修复**（`9182fa3`）：把 `@langchain/langgraph-checkpoint` 加成 `apps/api` 的直接依赖并锁定 `0.1.1`，不再依赖 override 选择器。

## 保留：更通用的问题仍然成立，值得单独加固

`pnpm.overrides` 的 `parent>child` 选择器语法对**常规 dependency** 解析有效，但对这里这种 **peerDependency 自动解析**不可靠（pnpm 已知限制类目）——`@langchain/langgraph-checkpoint-postgres@0.1.2` 把 `@langchain/langgraph-checkpoint` 声明成 peerDependency（range `^0.1.0`），任何触发全仓库重新 resolve 的操作（哪怕是给完全无关的包 `pnpm add` 一次）都可能让这条边被解析出不满足该 range 的版本，且 pnpm 只告警（`unmet peer`）不报错——静默装错版本。

目前仓库里 `parent>child` 选择器语法的 override 只有这一条（已核实 `grep` 全仓库 `package.json`），且已经被更可靠的直接依赖声明取代，**当前没有已知的活跃风险点**。保留本 issue 是为了：
1. 记录这个 pnpm 选择器语法的已知限制，避免以后又有人在类似场景复用这个语法、复现同一个坑。
2. 评估是否要把根 `package.json` 里现有的 `overrides` 条目也一并移除（现在是冗余的，direct dependency 已经生效；留着不会造成新的错误，但会误导后来者以为它在起作用）。

## 建议排查方向（未验证，留给认领者）

- 移除根 `package.json` 里现在冗余的 `"@langchain/langgraph-checkpoint-postgres>@langchain/langgraph-checkpoint": "0.1.1"` override，避免误导。
- 评估仓库里是否有其他"依赖某个仅通过 peerDependency 满足的版本约束"的场景，是否也该改用直接依赖声明这个更可靠的模式。
- 升级 `@langchain/langgraph-checkpoint-postgres`/`@langchain/core` 到相互兼容的新版本组合，从根源消除锁定的必要性。

## 影响

优先级降为低——已知实例已修复，且未发现其他活跃风险点，纯粹是"避免以后重蹈覆辙"的加固/清理工作。

Start with the root package.json and inspect the existing @langchain/langgraph-checkpoint-postgres>@langchain/langgraph-checkpoint override alongside the direct dependency added in PR #2613. Search package.json files for similar peerDependency version constraints and confirm whether the override is redundant. Done means removing or retaining it with a documented rationale and identifying any other concrete cases needing direct dependencies.

Written by the indexing model from the issue text.