test(content): V26 应用后 chapter-create-delete e2e 转正(全量 43/0 全绿)

V26(章节/Block order_no uk 改 partial index WHERE deleted=false)已 flyway 应用(now at v26),
curl 实证建 order=2 章节(之前撞软删行 → 500)→ code:0。chapter-create-delete.spec.ts 由 test.fixme
转回 test(),建→删配对通过;全量 e2e 43/0(原 +1 fixme 现转正、0 skipped)。

content 写路 + 软删 uk 修复完整闭环:chapter create/work delete 前端契约 + chapter/block order_no
后端 schema 双修验证通过。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

muse-studio/e2e/chapter-create-delete.spec.ts

@@ -20,14 +20,12 @@ async function seedToken(page: Page): Promise<void> {
   }, TOKEN);
 }
 
-// FIXME(后端待修):前端契约已补齐(commandId + expectedWorkRevision),create 在干净作品上可成功(curl 实证 code:0);
-//   但后端 createChapter 用 orderNo = selectCountByWorkId(active)+1,而章节软删后行仍在表、
-//   uk_muse_content_chapter_work_order 不含 deleted(对比同文件 uk_muse_content_chapter_command 是 partial index)
-//   → 删章节后再建 order_no 与软删行冲突 → 500。系统性 schema/软删语义问题(chapter create/reorder 受影响,
-//   block 等表同形(已确证 block create 同 selectCount(active)+1 bug)。修法已写入
-//   sql/muse/V26__fix_content_softdelete_order_uk_partial.sql(chapter/block order_no uk 改 partial index
-//   WHERE deleted=false);待人类重启 48080 应用 flyway(DDL 改真 PG 归人类执行)后改回 test() 转正。
-test.fixme('用户新建并删除章节(真实后端写命令:commandId + 作品乐观锁)', async ({ page }) => {
+// 章节"建→删→再建同序号"端到端(双修后转正):前端缺契约字段(commandId + expectedWorkRevision)→ 真后端 400,
+//   补齐后请求合法到达后端,又暴露后端 order_no 软删碰撞——createChapter 用 selectCount(active)+1、
+//   软删行仍占 uk 名额(uk 漏 deleted)。后端 V26(sql/muse/V26__fix_content_softdelete_order_uk_partial.sql,
+//   chapter/block order_no uk 改 partial index WHERE deleted=false)已应用,软删行不占名额,删后重建不再 500。
+//   均已修(见 docs/mvp/进度总账.md)。
+test('用户新建并删除章节(真实后端写命令:commandId + 作品乐观锁)', async ({ page }) => {
   await seedToken(page);
 
   await page.goto('/workspace/1');