fix(responses): emit input_tokens_details / output_tokens_details in Responses usage

[warelik]

中文 TL;DR

Responses usage 之前只有 input/output/total，缺 *_tokens_details。补齐
input_tokens_details / output_tokens_details（text 由 total 减 cached/reasoning 推导，
上游若给了显式 text_tokens 则优先）。

Summary

Spec-completeness for the OpenAI Responses API usage object, which strict
consumers (Grok Build, codex-style clients) expect to carry the *_tokens_details
breakdown.

Fix

• src/handlers/responses.js mapUsage: emit input_tokens_details
  (text / audio / image / cached) and output_tokens_details
  (text / audio / reasoning), deriving text_tokens by subtracting
  cached / reasoning from the totals and preferring an explicit upstream
  text_tokens when present.

Test plan

• test/responses.test.js +2: non-zero cached/reasoning subtraction, explicit
  text_tokens precedence; existing usage assertions updated to the richer shape
• Full suite: npm test → 2763 pass / 0 fail

Branch is on current master (v3.5.0), applies cleanly.

[dwgx]

已合并,谢谢 🙏 这个 PR 有个你可能还不知道的巧合:它和我这边同期做的一件事正好是一条链的两半。

我前两天用付费 teams 账号校准了 DEVIN_CONNECT 响应里 cache 计数的 wire tag(issue #220):cache_read_tokens 是 metadata #7 的 tag 5 —— 免费账号上这个值是 0、protobuf 不编码零值,所以字段根本不出现,一直没法校准。校准之后缓存命中数进得了 chat 层的 prompt_tokens_details.cached_tokens,但当时它到不了 Responses API,因为 mapUsage 只映射三个总数。你这个 PR 正好把出口补上了。

合并后我用实测的真实数字串了一遍端到端:

输入: prompt_tokens=3554, cached_tokens=3328   (真实 A/B 数据)
输出: input_tokens_details.cached_tokens = 3328  ✅
      input_tokens_details.text_tokens   = 226   ✅ (3554-3328)

text_tokens 优先用上游显式值、没有才用减法推导 —— 这个优先级设计对,因为将来上游真给了 text_tokens,减法推导就未必等价了(可能还有别的 token 类别)。

顺带:既然现在出口通了,我把 DEVIN_CONNECT_BILLING_TAGS 的默认值改成了 cache_read_tokens=5(原本 opt-in)。不然默认部署下 cached_tokens 永远是 0,你补的这两个 details 对象就白瞎了。免费账号上零值不编码,所以默认开是安全的。

已加入致谢名单,评级 A。