🔍 Real behavior proof

1. 架构一致性证明

compactionTimeoutMs 在 runEmbeddedAttempt 中已被用于两个 compaction 相关路径，本 PR 将其复用到第三个路径（aggregate timeout），保持同一值的一致性：

逻辑: 如果 180s 对 compaction 模型调用足够（内层 safety timeout），对外层等待也应该足够 — compaction 在同一时间段内要么完成、要么被内层超时杀死。

2. 配置解析链路已验证

resolveCompactionTimeoutMs() 的测试覆盖（compaction-safety-timeout.test.ts）：

✓ returns default when timeoutSeconds is not set
✓ converts timeoutSeconds to milliseconds  
✓ preserves explicit timeoutSeconds above 600
✓ floors float timeoutSeconds (120.7 → 120)
✓ falls back for zero timeoutSeconds
✓ falls back for negative timeoutSeconds
✓ falls back for NaN timeoutSeconds
✓ falls back for Infinity timeoutSeconds

3. Aggregate timeout 函数本身已验证

compaction-retry-aggregate-timeout.test.ts — 16/16 通过：

✓ times out and fires callback when compaction retry never resolves
✓ keeps waiting while compaction remains in flight
✓ times out after an idle timeout window  
✓ does not time out when compaction retry resolves
✓ caps aggregate timeout before scheduling
✓ propagates immediate waitForCompactionRetry failures
✓ handles waitForCompactionRetry rejection after timeout wins
✓ propagates abort errors from abortable and clears timer

4. 行为变更分析

5. Issue 证据关联

Issue #94391 包含完整 trajectory 证据（session 91f28c2c），证明：

• compaction 模型调用完成时间：143s、174s、187s（均在 60s 后、180s 内）
• 调用完成标志：aborted=False, externalAbort=False, timedOut=False
• 60s 硬编码在每次调用完成前 ~83-127s 就标记 incomplete

本 PR 将 aggregate timeout 从 60s → 180s（默认），使这些已完成调用有机会被正常消费。

ClawSweeper status: review started.

I am starting a fresh review of this pull request: fix: #94391 将 compaction aggregate timeout 从硬编码 60s 改为读取 compaction.timeoutSeconds 配置 This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

Superseded by #94421 which fixes the root cause (isCompactionStillInFlight signal during active retry streaming) rather than changing the timeout value. #94421's approach is superior: it preserves the 60s idle guard while correctly treating active model streaming as work-in-progress, so valid long-running retries are not abandoned.