fix(ui, cli): humanize provider retry delay (3401)

[yunaremaia]

Fixes #3401.

When a provider returns a long Retry-After (~13565s for a 5h quota reset), the retry banner renders Retrying in 13565s / 13565 秒后重试 — illegible. Related to #3393 (countdown ticking).

What changed

• packages/ui/src/conversation-copy.ts — new formatRetryDelay(seconds, locale): 13565 → 3h 46m 5s (en) / 3小时 46分 5秒 (zh), 1s granularity. Wired into both zh/en providerRetryScheduled catalog entries.
• packages/cli/src/pi-transcript.ts — new formatRetryDuration(delayMs) for the TUI activity strip; same humanized output (en).

Granularity stays at one second so the banner visibly ticks (minute-granularity would reintroduce the frozen look from #3393).

Verification

• formatRetryDelay spot-checked locally (13565→3h 46m 5s, 90061→1d 1h 1m 1s, edge: 0.2→1s).
• No registry workaround; change is compile-only (no new deps).
• Full local build/test not run — relies on @xterm/xterm custom registry (ms-feed-2.pkgs.visualstudio.com); CI is the verification layer.

Closes #3401.
Related: #3393.

[Astro-Han]

Reviewed exact head 742bbc9. Coverage: UI zh/en duration formatting over seconds/minutes/hours/days and fractional-second rounding; CLI millisecond formatting and narrow-line fitting; provider-retry event bounds/countdown flow; confirmation that Runtime retry-after/backoff calculation, sleep, attempts, and protocol transport are unchanged. Exclusions: real provider Retry-After traffic and interactive terminal/renderer visual inspection. Local UI→CLI builds passed and 228 focused UI/CLI tests are green; hosted exact-head test is green. No P0–P3 findings. The branch is 24 commits behind main and currently conflicts only in packages/ui/src/conversation-copy.ts; rebase should preserve current main’s newer copy entries plus this PR’s formatter/wiring.

[Astro-Han]

I rebased this branch onto the latest main for you. The new head is 19c54698d.

The branch had a real conflict with main, not just a textual one: main added provider_capacity to providerRetryReason after this branch forked, so merging as-is would have deleted provider_capacity from both the zh and en copies. The rebase keeps main's provider_capacity and only replaces providerRetryScheduled with formatRetryDelay(...), so the change stays exactly as you wrote it.

Local verification: @maka/ui typechecks and all 227 tests pass. Once CI is green on the new head I will re-review and move this along.

简体中文

我帮这个分支 rebase 到了最新的 main（新 head 19c54698d）。

原来的分支和 main 已经有实质冲突：main 在这条分支之后给 providerRetryReason 增加了 provider_capacity，而这个分支的 conversation-copy.ts 是在此之前分叉的，直接合并会把中英两处的 provider_capacity 一起删掉。rebase 时我保留了 main 的 provider_capacity，只把 providerRetryScheduled 换成 formatRetryDelay(...)，改动范围和你原来的提交一致。

本地验证：@maka/ui 类型检查通过，227 项测试全过。等 CI 在新 head 上跑绿之后我再重新 review 并推进合并。

[Astro-Han]

Approving at head 19c54698db6f7f0b878416e7ee4ffbbd4a7d74a4. Hosted test is SUCCESS on this exact head.

Disclosure: I produced this head — the branch conflicted with main and I rebased it. So to be explicit about what I checked rather than what I wrote:

• The net contribution is still only the author's two files, pi-transcript.ts (+16) and conversation-copy.ts (+27).
• provider_capacity, which main added to providerRetryReason after this branch forked, is present twice in the rebased file — once for zh and once for en. That is the entry a naive conflict resolution would have deleted.
• Only providerRetryScheduled was rewritten to call formatRetryDelay(...); nothing else in those long copy lines changed.
• @maka/ui typechecks and all 227 tests pass locally.
• Against the current main, neither conversation-copy.ts nor pi-transcript.ts has any competing change, so there is no semantic overlap to re-check.

One follow-up for a separate PR, not blocking: pi-transcript.ts reimplements the same d/h/m/s ladder as formatRetryDelay instead of reusing it, and this PR ships no tests. #3402, which I closed as superseded by this one, has unit tests for exactly this function — worth bringing over.

简体中文

在 head 19c54698db6f7f0b878416e7ee4ffbbd4a7d74a4 上给出 approve，这个精确 head 上的 test 是 SUCCESS。

需要说明：这个 head 是我做的——分支和 main 冲突，是我帮忙 rebase 的。所以把我核对过的内容列清楚：

• 净贡献仍然只有作者那两个文件：pi-transcript.ts（+16）和 conversation-copy.ts（+27）。
• main 在这条分支分叉之后给 providerRetryReason 加的 provider_capacity，在 rebase 后的文件里出现两次（中英各一），这正是机械解冲突会删掉的那一项。
• 只有 providerRetryScheduled 被改成调用 formatRetryDelay(...)，那几行长文案里其余内容没动。
• @maka/ui 类型检查通过，本地 227 项测试全过。
• 对照当前 main，conversation-copy.ts 和 pi-transcript.ts 都没有竞争性改动，没有语义重叠需要复核。

一条不阻塞的后续建议：pi-transcript.ts 自己又实现了一遍和 formatRetryDelay 相同的 d/h/m/s 阶梯，没有复用；而且这个 PR 没有带测试。被它取代、我已关闭的 #3402 里正好有这个函数的单测，值得挪过来。

[Astro-Han]

LGTM, merging.

中文

LGTM，合并中。

[Astro-Han]

Merged as 1e1c886aec7b476a6bd5550088e65c38df327e06.

简体中文

已合并：1e1c886aec7b476a6bd5550088e65c38df327e06。