`claudecode-timeout` input is not enforced — action runs past the configured limit on a stalled scan

[buzbrain]

Summary
When the underlying Claude analysis stalls (e.g. during an Anthropic server-side model degradation), the claudecode-timeout input does not reliably bound the run. We set claudecode-timeout: '10' but a stalled invocation ran ~27 minutes — well past both the configured 10 min and the documented 20-min default — until an outer GitHub timeout-minutes step-timeout killed it.

Expected
With claudecode-timeout: '10', the action aborts its own analysis at ~10 min and exits.

Actual
The analysis kept running past 10 min (and past the 20-min default) on a stalled scan; only a workflow-level timeout-minutes on the step stopped it. This makes the input ineffective as a cost/hang guard — consumers must add their own step-level timeout as a backstop.

Repro / evidence

• Action ref: @main = 0c6a49f1fa56a1d472575da86a94dbc1edb78eda (unchanged since 2026-02-11).
• CLI version identical across healthy and hung runs (2.1.197) — no version delta.
• Healthy scans finish in ~1 min; stalled scans ran 12–27+ min despite claudecode-timeout being set lower.
• Stall events clustered on 19 Aug 2026; partially overlapping Anthropic status-page degradation incidents 16–19 Aug (incl. 19 Aug 09:42–11:02 UTC on Opus, the action's default model).
  (Run URLs are in a private repo and not linkable here; happy to share details.)

Ask
Enforce claudecode-timeout as a hard internal deadline that aborts the Claude call, independent of the model responding.