`ocr review --timeout` does not extend the five-minute LLM request deadline

[acoliver]

Environment

• open-code-review v1.11.3 (b3badd376), darwin/arm64
• JSON agent-mode range review
• One selected Rust file, zai-anthropic provider, glm-5.3, concurrency 1

Reproduction

Run a single-file review with an outer timeout larger than five minutes:

ocr review \
  --audience agent \
  --format json \
  --provider zai-anthropic \
  --model glm-5.3 \
  --concurrency 1 \
  --timeout 30 \
  --from BASE \
  --to HEAD \
  --exclude 'all,other,changed,files'

The selected file was 291 lines. Planning completed on the first run, but the main request failed after exactly five minutes. The manifest reported:

{
  "classification": "timeout",
  "reason": "file review exceeded its time limit",
  "duration_to_headers_ms": 300002
}

Resuming the session with the same --timeout 30 started planning again rather than reusing the completed plan. That planning request also failed at exactly five minutes before OCR moved to the main request.

Grouped reviews showed the same duration_to_headers_ms of about 300,000 ms despite --timeout 600.

Expected behavior

--timeout, documented in minutes as the concurrent task timeout, should either:

1. apply to the provider request deadline needed to complete that task, or
2. document the independent five-minute provider-request ceiling and retry requests that time out before the task deadline.

A resume should reuse a completed plan when the file's main review was the failed stage.

Impact

A review can repeatedly fail to cover one changed file even when the caller grants a larger task timeout. The JSON correctly marks coverage as failed, but there is no CLI setting that allows the file review to finish.

[zhuangzhewei09]

Hi, I'd like to investigate the timeout-handling part of this issue. I checked the reported revision and found that per-request timeouts are already configurable through OCR_LLM_TIMEOUT and provider timeout_sec, independently of --timeout. I'll first reproduce the request-versus-task deadline behavior and verify timeout retries, then propose a focused fix with regression tests and clearer CLI diagnostics/help. In particular, a request timeout may currently be reported as the file's task deadline being exceeded. I'd keep completed-plan reuse as a separate follow-up. Is anyone already working on this scope, and do maintainers prefer keeping the two timeout controls independent or changing how --timeout interacts with the request deadline?