docs(merchant): 关闭存量商户恢复票并解除新商户流程阻塞

用户确认不再需要 6666000241335656 做测试，工单 02 关闭。02 存在的意义是先用已有
商户把通道能力验证掉、避免用新商户反复试错在控台留下只能关闭不能删除的记录；
这件事已经完成，所以关掉它不损失任何东西。

- 02 标记 wontfix 并加关闭注释，逐条说明产出不因此作废：三个真实缺陷修复已作为
  c18b9fa 合入，通道能力（三场景即时入驻成功、延迟入账生效、人才端 AppID 绑定）
  已用真实接口证明并归档在 96c32c2。工单文件与证据保留，不删除。
- 03 的 Blocked by 由 02 改为无、可立即开始，并说明开工门槛并未降低：原阻塞条件
  想保证的“通道能力已被真实证明”已经满足，证据在核验文件里。What to build 同步
  去掉“02 真实验收通过后”的开头。
- 03 那项“进度去硬编码”改写为“去掉只服务一张商户的恢复路径”。随 02 关闭，
  RECOVERY_HUIFU_ID 及 configureDelay／advanceDelay 已无使用对象；同时记录一个
  简化：新商户的延迟入账随业务开通请求一并生效（delay_flag=Y 已在请求里），
  不需要单独的补配步骤。
- 04 的成立理由重写：不再是解开 02 ⇄ 03 死锁，而是“任何商户要能收款都需要实名”，
  完成演示从存量商户改为新商户。
- 规格里“先存量、后新商户”的两阶段框架与阶段切换条件整体作废：文首加 2026-09-16
  修订说明，并同步改写存量恢复、两票并行、真实联调、风险应对、交付完成条件等
  承载该框架的条文；指定存量商户只保留为通道能力的验证来源。
- ticket-plan 改为两张并行工单，并新增一节记录两票的冲突面（进度服务、商户端
  进件表单、共享文件），供并行开工时参照。