tune(provider): resume 首字节超时 45s→60s — 让"慢但活着"的响应过关

实测当 Anthropic 首字节延迟偶尔飙到 ~43s(响应仍活着,只是慢),45s 窗口会把
它误判成卡死、白烧一次 45s 再重试,单步代价 90s+。抬到 60s 让这些慢响应在
attempt 1 直接通过。真卡死多等 15s,但有连续卡死熔断(streak≥2)兜底。
可经 config.extra["claude_resume_first_byte_timeout"] 覆盖。

实况验证:一条工作区 run 在 14:13~14:18 撞上这波延迟(全新小 session 也卡、
时好时坏 43s),三层容错(轮换/保留/重试)扛住没死,随后 API 恢复、run 自愈
回 6-13s。本调整针对"API 当前延迟高"对症,与三层正交。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

lambdagent/src/lambdagent/providers/claude_code_provider.py

@@ -44,8 +44,11 @@ _DEFAULT_FIRST_BYTE_TIMEOUT_S = 120.0
 # 120s here means a wedged large-context resume burns 120s×2=240s before
 # failing; warm resume never legitimately needs that long. Use a tighter
 # window so a stalled resume is detected fast and the engine can recover.
+# 但实测 Anthropic 首字节延迟偶尔飙到 ~43s(仍活着、慢)——45s 会把这些
+# "慢但活着"的响应误判成卡死、白烧一次 45s 再重试。抬到 60s 让它们在
+# attempt 1 直接通过;真卡死多等 15s 也有连续卡死熔断兜底。
 # Override via config.extra["claude_resume_first_byte_timeout"].
-_DEFAULT_RESUME_FIRST_BYTE_TIMEOUT_S = 45.0
+_DEFAULT_RESUME_FIRST_BYTE_TIMEOUT_S = 60.0
 # 会话轮换:claude-code `--resume` 一个变大的 session 会首字节卡死(实测 resume
 # 一个 204 行/395KB 的 session 超过 60s 没首字节，而全新会话 8s 秒回)。每 N 次
 # resume 后主动开新会话，让 session 永远停在"小而快"的区间。0=不轮换。