[BUG] model-recovery 的 transient 判定依赖错误字符串里的数字 —— account 面一旦补分类码就会把「可恢复」误判成「失败」 #965

这是什么

packages/ui-mac/src/renderer/alpha-ui/model-recovery.ts:26 用
/^http-(408|425|429|5\d\d)$/ 判断一次失败是不是暂时性的（该显示「正在恢复」还是「失败」）。

也就是说：它的控制流依赖错误字符串里的那个数字。

而 account 面的 authed 现在也走 httpErrorCode（#918 / #940 / #955 收编咽喉之后）。
httpErrorCode 的语义是「有合法 code 就返回 code，没有才回落 http-<status>」。

⇒ account 服务将来只要给 5xx 补一个分类码，r.error 就不再是 http-503 而是那个码，
正则不匹配 ⇒ 本来该显示「正在恢复」的状态被判成 「失败」。

为什么现在开票（今天它不成立）

今天 account 面不发码（ap#330 的勘破实读确认：account-server.ts 的 54 个拒绝点一个码都没有），
所以这条今天走不到。开票是因为它与刚修完的 #963 是同一形态：

控制流依赖错误字符串的形状，而那个形状由另一个仓的另一个人决定。

#963 那条（删自动化的 r.error !== "http-404"）今天成立恰恰靠平台不给 404 补码，
一旦补上，用户就再也删不掉那条自动化，而两边的门都不会红。这一条是同一个雷，只是还没被踩。

#963 的实现方在收工时主动登记了它，并说明为什么不在那张票里顺手改：
account 面今天没有结构化 status 的消费者，改它是投机形状变更，而且平白靠近这条字符串面。
那个判断是对的 —— 所以单独开票。

边界

model-recovery.ts 的 transient 判定，以及它与 account 面 authed 返回形状的关系。

不要为此去改平台/account 服务（ap#330 已裁决不走「统一补码」那条路，基线已订正）。

退出条件

• 先勘破：model-recovery.ts 今天消费的 error 到底由哪条链产出、有几个来源？
  除了 authed，还有没有别的地方喂它？两条独立检索轴交叉，grep -a。散文断言不算勘破。
• 修法方向（勘破后再选，参照 #963 的根修形态）：让 transient 判定拿到结构化的 status，
  而不是从字符串里抠数字 —— 那样这条依赖就消失了，不需要再有判据去防「account 别补码」。
• 判据落在用户可观察结果上：account 面 5xx 带码时，UI 仍显示「正在恢复」而不是「失败」。
  不要断言正则的返回值。
• 反向判据不能省：真正不可恢复的失败（4xx 非 408/425/429）仍须显示「失败」，
  否则会把一个永远好不了的状态显示成「正在恢复」，用户白等。
• 写完自己实施一遍绕过：改回从字符串抠数字，带码 5xx 那条判据必须转红。

复杂度：S。来源：#963 实现方收工登记（2026-08-14）。Refs #963、#918、#955、jinjunnn/alpha-platform#330。