docs(bug-history): renumber this batch to 260-262 after staging took 254-259

Second collision in one delivery: origin/staging advanced from c8d9ec64 to
e1db5762 while the test suite was running and claimed 256-259, so the three
records in this batch move to 260, 261 and 262 with their cross-references
updated. Titles differ from every remote record, so BUG-254's rule assigns new
numbers rather than merging.

BUG-260's related-records field now states the limit this exposes: searching
for the highest number before appending only holds at the moment of writing
and cannot survive the remote advancing before the push.

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/BUG_HISTORY.md

@@ -3847,7 +3847,7 @@
 - 相关记录：BUG-260 无前序同类记录。本记录三次改号：初次写作取 255；第一次 rebase 到 `origin/staging`（`c8d9ec64`）时远端已占 254–255，改 256；第二次 rebase 到 `e1db5762` 时远端又占到 259，改 260。每次都按 BUG-254 的防复发要求处理——标题与远端各记录均不同，故另分新号而非合并。BUG-253 所记的抢号失效模式在同一轮交付里连续复现两次，暴露出「追加前检索最大编号」这条措施的边界：它只在写记录那一刻成立，防不住推送前远端继续前进。可靠做法是把定号推迟到推送前最后一次 rebase 之后。
 - 修复版本：本地未提交候选
 
-## BUG-257 | staging web 镜像把 `skills/` 拷两遍，符号链接撞上被解引用的同名目录
+## BUG-261 | staging web 镜像把 `skills/` 拷两遍，符号链接撞上被解引用的同名目录
 
 - 状态：resolved
 - 首次发现：2026-08-17
@@ -3860,10 +3860,10 @@
 - 验证：修复后完整构建镜像成功（`naming to docker.io/library/jyotisha-web:fixed done`）。进镜像逐项核对：`/app/skills` 下 1208 个文件、`assets` 仍是 `lrwxrwxrwx ... -> ../../assets` 且 `ls` 能列出其中文件、`/app/frontend/server.js` 存在。运行时冒烟：容器启动打印 `▲ Next.js 16.3.1`，`GET /` 返回 200（日志中的 `SupabaseConfigurationError` 是未注入环境变量所致，属预期）。对照实验确认与本批 Next 升级无关——在升级前的 `3371baca`（`next` 16.2.10）上用同一条命令构建，在同一步报同一条错误。
 - 待跟进：**本条没有自动化回归测试**，与 BUG_HISTORY 工作流对 `resolved` 的要求存在缺口，此处如实标注而非掩盖。原因是复现该缺陷必须真的构建镜像（本机约 16 分钟），放不进 `npm test`。可行的折中是在 `tests/health-deployment.test.ts` 加一条结构断言：若 Dockerfile 同时存在「拷贝 standalone 到 `/app`」与「显式拷贝 `skills`」两行，则必须存在删除追踪副本的一行。这是结构守卫而非行为回归，能防住这一行被顺手删掉，未在本轮加入。更彻底的方向是消除 `skill-package-registry.ts` 的动态文件访问以恢复精确追踪，那属业务代码改动，另开一轮。
 - 防复发：Next 的输出文件追踪会把项目文件带进 `.next/standalone/` 并**把符号链接解引用成真目录**；任何 Dockerfile 若既拷 standalone 又显式拷同名目录，两者就在争同一路径，必须显式指定谁赢，不能靠 COPY 顺序碰运气。仓库内 git 跟踪的符号链接（如 `skills/*/assets`、`skills/*/references`、`skills/*/scripts`）是这类冲突的固定诱因。更普遍的教训：镜像构建在 CI 上绿不等于 Dockerfile 正确，凡涉及符号链接与目录同名的 COPY，判定必须落到「换一个 BuildKit 快照器是否仍然成立」。
-- 相关记录：BUG-257 无前序同类记录。与 BUG-256 同批交付但成因无关，是为验证 BUG-256 的 Next 16.3.1 升级而首次在本地构建 staging 镜像时暴露出来的。
+- 相关记录：BUG-261 无前序同类记录。与 BUG-260 同批交付但成因无关，是为验证 BUG-260 的 Next 16.3.1 升级而首次在本地构建 staging 镜像时暴露出来的。编号顺延过程见 BUG-260 的相关记录。
 - 修复版本：本地未提交候选
 
-## BUG-258 | staging 镜像内 `posthog-node` 的 Node 引擎要求高于基础镜像实际版本
+## BUG-262 | staging 镜像内 `posthog-node` 的 Node 引擎要求高于基础镜像实际版本
 
 - 状态：investigating
 - 首次发现：2026-08-17
@@ -3876,5 +3876,5 @@
 - 验证：不适用（未修复）。已核实的事实见根因。
 - 待跟进：先确定这是真风险还是纯噪声——读 `posthog-node@5.41.0` 的 changelog/引擎声明来源，确认它把下限提到 `>=22.22.0` 是因为用了新 API 还是仅仅是维护者的支持策略。若属后者，本条可降级为「已知噪声」并就地记录，不必改依赖。
 - 防复发：镜像构建日志里的 `EBADENGINE` 不得当作噪声跳过——它意味着依赖声明的运行环境与镜像实际提供的不一致，而 npm 不会阻止这种安装，因此它是少数「构建期唯一一次提示、之后只会在运行期爆发」的信号。基础镜像用浮动 tag（`node:22-alpine`）时，实际 Node 版本会随上游重建漂移，依赖的引擎下限也会随升级上移，两者相向移动，这类不匹配会反复出现。
-- 相关记录：BUG-258 无前序同类记录。与 BUG-257 同为首次本地构建 staging 镜像时暴露的构建期问题。
+- 相关记录：BUG-262 无前序同类记录。与 BUG-261 同为首次本地构建 staging 镜像时暴露的构建期问题。
 - 修复版本：未修复