feat: rename bugfix-ship/requirement-flow to short-ship/long-ship with shared ship records

short-ship and long-ship share one ship-id record under .pouch/ship/<id>/.
specifier writes PRDs into spec/; delivery-loop appends evidence pointers.
Old names stay as deprecation stubs so existing installs keep working.

skills/ship/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: ship
+description: >-
+  short-ship、long-ship、pr-ship、specifier 共用的交付记录格式。一次交付一个
+  ship-id，目录在 .pouch/ship/<id>/。不单独作为用户入口；用户说 short-ship、
+  long-ship、交付记录、ship id 时由对应入口读取本 skill。
+---
+
+# Ship：一次交付的记录
+
+这是内部记录契约，不替用户选择 short 或 long，也不执行构建或部署。
+
+## 使用方式
+
+入口 skill 在拿到或创建 `ship-id` 之后读取 [record.md](references/record.md)。
+创建目录用 `scripts/create_ship.py`，改证据指针用 `scripts/append_evidence.py`，
+写回后跑 `scripts/validate_ship.py`。
+
+## 不可违反的规则
+
+- 进入 short-ship / long-ship / pr-ship 的第一件事是拿到或创建 `ship-id`。没有 id
+  不得改业务代码、不得跑 tester / obtain / deploy。
+- 记录只写 `.pouch/ship/<ship-id>/`。功能、小改动和本次修复的任务不要写入
+  `.pouch/ack/tasks.yaml`。ACK 任务板只收缺陷；缺陷要交付时在 ship 的 `source` 里引用。
+- `ship-id` 用稳定短 slug：小写字母开头，小写字母、数字、连字符，最长 64。不要用日期、
+  随机数或当前分支名冒充业务 id。
+- 短长同一套字段。`kind: short` 恰好 1 条 task；`kind: long` 是 DAG，子任务默认不是
+  新的 ship。
+- tester / builder / deployer 的 SSOT 仍在各自目录。ship 只追加指针。本轮跑过的
+  测试、obtain、部署若没写入 `current.yaml` 的 `evidence`，该阶段不算完成。
+- 项目构建/部署契约仍在 `.pouch/ack/delivery.yaml` 和 builder/deployer 配置里，不要
+  复制进每个 ship。
+- 旧的 `.pouch/specifier/features/<id>/` 在继续该需求时迁到
+  `.pouch/ship/<id>/spec/`，规则见 record.md。
+
+## 结果
+
+有效 ship 目录含 `current.yaml`、`spec.md`、`tasks.yaml`、`status.md`；long 另有
+`spec/` 下的 PRD 与 handoff。校验通过后入口 skill 才能继续交付。