chore: increase Cloud Rewrite timeout from 2s to 5s

[ZhaoChaoqun]

Summary

• Cloud Rewrite API 的 wall-clock 超时从 2s 增加到 5s，减少网络较慢时的误超时
• URLRequest 安全网超时从 3s 相应调整为 8s

Test plan

• 验证正常网络下 Cloud Rewrite 仍能在 5s 内返回
• 验证超时后仍能正确 fallback 到原始文本

🤖 Generated with Claude Code

[claude]

🔥 这个 PR 编译不过

AnalyticsService 在整个仓库中不存在——不在 Sources/ 下，不在任何分支上，也没有通过 SPM/CocoaPods 引入。你往 CloudRewriteService.swift 里加了 7 处 AnalyticsService.track() / AnalyticsService.latencyBucket() / AnalyticsService.lengthBucket() 调用，但类型本身根本没有定义。

这意味着这个 PR 在编译阶段就会直接挂掉。PR 标题说的是「increase timeout from 2s to 5s」，那超时值的改动是对的，但你顺手塞进来的 analytics 代码引用了一个不存在的类型。

要么把 AnalyticsService 一并加进来，要么把 analytics 的改动拆到另一个 PR 里——在那个 PR 里先引入 AnalyticsService。不要把编译都过不了的代码合进 main。

---

elapsedMs 计算不一致

成功路径（精确到毫秒）：

let elapsedMs = Int(elapsed.components.seconds * 1000) + Int(elapsed.components.attoseconds / 1_000_000_000_000_000)

三个错误路径（只有秒级精度，丢失毫秒部分）：

let elapsedMs = Int(startTime.duration(to: .now).components.seconds * 1000)

错误路径漏掉了 attoseconds 的转换。如果请求在 1.8s 失败，latencyBucket 会报 1000ms 而不是 1800ms。同一个指标两套计算逻辑，自己给自己埋坑。

---

Analytics 代码大量重复

4 个 catch 分支里几乎一模一样的 AnalyticsService.track(...) 调用，应该提取成一个辅助方法，传入 outcome/errorType 等参数即可。复制粘贴不是工程。

---

评分：4/10

维度	得分	说明
正确性	0/3	引用不存在的类型，编译直接失败
简洁性	1/2	超时改动本身干净，但 analytics 代码大量重复
可读性	2/2	命名清晰，意图明确
可维护性	1/2	track 调用在多个 catch 分支复制粘贴
安全性	0/1	编译都不过，无从谈起

结论：REQUEST_CHANGES。先解决 AnalyticsService 不存在的问题，统一 elapsedMs 计算逻辑，消除重复代码，再重新提交。