[BUG] 删自动化的幂等容忍靠比错误字符串撑着 —— 根修:让 authed() 带出 status,404 即视作已删 #963

用户会遇到什么

在 app 里删一条自动化，如果它的云端定时任务已经不在了（另一台设备删过、清理过、上次删除超时后重试），
今天能删成功。但这件事是靠运气成立的——一旦平台给 404 补上一个 code，
用户就再也删不掉那条自动化了，而且重试永远同样失败（云端那行本来就没了）。

链条（逐行核过）

packages/ui-mac/src/main/automation-ipc.ts:66-67
    const del = await deleteCloudSchedule(prev.cloudScheduleId)
    if (!del.ok) return { ok: false as const, reason: del.reason }   ← 立刻 return
    ...
:69 const res = deleteAutomation(id)                                  ← 永远执行不到

packages/ui-mac/src/main/alpha-cloud-schedules.ts:86
    if (isErr(r) && r.error !== "http-404") return { ok: false, reason: `云端删除失败:${r.error}` }
                    ^^^^^^^^^^^^^^^^^^^^^^ 幂等容忍 = 拿错误字符串跟 "http-404" 比

authed()（alpha-account-request.ts:57）在有 code 时把 status 丢掉了：
return { error: await httpErrorCode(res) } —— 所以下游只能去比那个字符串。
今天它等于 "http-404"，靠的正是平台不给 404 补码（ap#330 已实读确认 schedules 的 404 无码）。

两边的门都不会红：桌面的测试测的是 http-404，平台的测试测的是「有 code」，
各自都对，合起来坏掉。

根修（而不是给幂等键换个更聪明的字符串比较）

让 authed() 把 res.status 一并带出来，删除路径改成「404 即视作已删」。

这条修法的签名是:改完之后那条依赖彻底消失，连判据本身都不需要了 ——
不用再有任何东西去保证「平台不给 404 补码」。这正是本仓「根修优先于绕路」那条讲的形态：
修完不需要保留复杂判据防复发。

边界

• packages/ui-mac/src/main/alpha-account-request.ts 的 authed() 返回形状；
• packages/ui-mac/src/main/alpha-cloud-schedules.ts 的 deleteCloudSchedule。
• 不要改平台侧（ap#330 的勘破已证明「统一补码」那个方向体量约 290 处、且有一格结构上做不到）。
• 不要削弱 httpErrorCode 的 fail-closed 纪律（无合法 code ⇒ 保持 http-<status>，不猜）——
  本票只是让 status 除了被编进字符串之外，也能被结构化地拿到。

退出条件

• 先勘破：authed() 今天有几个调用点、各自怎么消费 error？改返回形状会不会打穿别的消费者？
  （尤其 model-recovery.ts 那条按 /^http-(408|425|429|5\d\d)$/ 判 transient 的——
  它依赖的是字符串里的数字，本票不能把它弄坏。）散文断言不算勘破。
• 判据落在用户可观察结果上：云端已无该定时任务时，在 app 里删自动化仍然成功、本地那条真的没了。
  不要断言 deleteCloudSchedule 的返回值。
• 反向判据不能省：云端删除因别的原因失败（403 / 503）时，仍然不删本地
  （否则会留下离线幽灵触发——那是 automation-ipc.ts:67 注释里点名要防的）。
• 模拟平台给 404 补码：构造一个带 code 的 404 响应，判据仍须绿 ——
  这一条正是本票存在的理由，它证明那条依赖真的消失了。
• 写完自己实施一遍绕过：把幂等键改回比字符串，带 code 的 404 那条判据必须转红。

复杂度：S。来源：ap#330 只读勘破（2026-08-13）+ 主 session 逐行复核。
Refs jinjunnn/alpha-platform#330、#918、#940。