Make the 120-second verify timeout configurable per repo

[dzykovic]

Problem

Both verify paths hard-code a 120 000 ms ceiling:

• engine/agents/runtime.ts (runVerify execFile timeout) — the creator-loop gate
• engine/verification/pipeline.ts (ScriptVerificationCheck default) — the pipeline check

A cold heavyweight build (dotnet solution restore+build, large monorepo) can exceed 120 s even when the toolchain is present and the verify command is correct. The failure then reads as "verify failed" rather than "verify timed out", and every creator PR gets stuck failing its gate. scripts.init already gets a 10-minute ceiling (WS_INIT_TIMEOUT, engine/infra/workspace-init.ts); verify has no equivalent knob.

This becomes acute for the sandbox deployment path (operator running inside a project's sandbox image with non-Node toolchains — exactly the workloads that path unlocks).

Proposal

• Add an optional per-repo limit (e.g. limits.verifyTimeoutMs in config/repos.yaml, or scripts.verifyTimeout in the managed repo's .operator/project.yaml) with the current 120 s as the default.
• Thread it through both exec sites; keep one source of truth for the default.
• On timeout, the failure reason must say "timed out after ms" (distinct from a non-zero exit) so the log stream distinguishes slow-but-correct from broken.
• Regression tests: one per exec site, pinning that the configured value reaches the subprocess options and that timeout produces the distinct reason.

Acceptance criteria

• Configurable ceiling honored by both verify paths; default unchanged (120 s).
• Timeout vs failure distinguished in logs and failure reasons.
• npm run typecheck && npm run lint && npm test green; coverage on touched files >= 90%.