What Problem This Solves

Fixes #100660.

In runLinkUnderstanding() (src/link-understanding/runner.ts), the HTTP fetch timeout for every link was resolved from entries[0] only. If later model entries had larger timeoutSeconds, the fetch could still time out using the first entry's shorter window. The fetch phase is independent of any single CLI execution, so it should use either an explicit global link-tools timeout or the largest configured model timeout.

Why This Change Was Made

Introduced resolveFetchTimeoutMsFromConfig() which:

1. Honors tools.links.timeoutSeconds when it is explicitly configured.
2. Falls back to Math.max(...) across all configured model timeouts so slower entries are not capped by the first one.

The timeout is now computed once per call instead of once per URL.

User Impact

Link-understanding fetches no longer fail prematurely when the first configured model has a shorter timeout than later models. Users who set a global tools.links.timeoutSeconds get predictable fetch timeouts independent of model ordering.

Evidence

Added two regression tests in src/link-understanding/runner.test.ts that both fail on current main:

• Global timeout test: with tools.links.timeoutSeconds: 15 and model timeouts 1 and 9, the fetch must use 15000 ms. On main it uses 1000 ms.
• Fallback test: with no global timeout and model timeouts 1 and 9, the fetch must use 9000 ms. On main it uses 1000 ms.

pnpm test src/link-understanding/runner.test.ts -- --run

All six tests in the file pass.