chore(ci): deps-image 超时 30 → 90 分钟（冷构建需 45min+，原值使镜像永远建不出来）

[sundevilyang]

问题（实测）

deps-image job 的 timeout-minutes: 30 小于冷构建的实际耗时：Dockerfile.deps 要在 2 核 runner 上 apt-get + mix deps.get --only prod + mix deps.compile 全量编译（AGENTS.md 自己记录「未命中在 2 核 runner 上重建可超 45min」）。

后果链（今天实测）：

1. mix.lock 变更（ash 3.33.3 → 3.33.4 修 CVE）→ 新 tag 8ac7c792660e0fb0；
2. CI 的 deps-image 检查发现镜像缺失 → 开始构建 → 30 分钟被掐死；
3. 镜像永远不会就位 → deploy 端只能走 fallback 现场重建（45–90min），AGENTS.md 明确说"别依赖它"；
4. 我查了最近 40 次 ci.yml run：deps-image 一次成功都没有（全 skipped/failed/cancelled）→ 这个"lock 变更自动重建"的机制实际上从未生效过（此前镜像很可能是人工在 Apple Silicon 上推的，也正是历史上 arm64 误推事故的来源）。

改动（一行 + 注释）

   deps-image:
     if: github.event_name == 'push'
     runs-on: ubuntu-latest
-    timeout-minutes: 30
+    # 冷构建（mix.lock 变更后首次）在 2 核 runner 上需 45min+（AGENTS.md 已记录），
+    # 原 30min 会把每次 lock 变更的构建都掐死 → 镜像永远缺失、deploy 端被迫 45–90min 现场重建。
+    timeout-minutes: 90

为什么选这条路（而不是本地 Mac 构建）

方案	架构安全	需要凭据	自动	结论
提高 CI 超时（本 PR）	✅ runner 恒 amd64	❌ 不需要	✅ lock 变更自动	采纳：机制修对，一次改永久生效
本机 --platform linux/amd64 构建推送	⚠️ 需人工核 manifest（历史事故就是漏 --platform）	✅ 需要 KAMAL_REGISTRY_PASSWORD（本机无）	❌ 每次手工	可作一次性加速，不作机制
deploy 端 fallback	✅	❌	✅ 但每次 45–90min	兜底，不主动依赖（AGENTS.md）

验证

• 合并后 develop 的 push run 里 deps-image 应在 ≤90min 内 success，日志出现 deps 镜像已就位（amd64） 或 构建并推送 + docker push 成功；
• 之后 docker manifest inspect -v ccr.ccs.tencentyun.com/codingirlsclub/cgc2046-backend-deps:8ac7c792660e0fb0 的 architecture 应为 amd64；
• 随后 develop→main 发版可正常命中 TCR（deploy ~4min，不再现场重建）。

非目标

不改 Dockerfile.deps 的构建内容；不引入 buildx cache（Dockerfile 注释已说明 mode=max 导出曾挂起）；不改 deploy 端 fallback（它仍是兜底）。