fix(community): normalize InfoQuest timeout config values like the sibling providers do - #5883

No linked issue (found by reading the provider against its siblings; steps below reproduce it).

Why

Trigger: deerflow.community.infoquest.tools reads five numeric options straight out of
config.yaml and hands them to InfoQuestClient unvalidated, while every sibling search/fetch
provider that reads a number (exa._coerce_positive_int, ddg_search._coerce_max_results,
serper, sofya, brave, image_search, jina_ai._coerce_timeout) normalizes first.

Pain: config.example.yaml documents these as seconds —

# Web fetch tool (uses InfoQuest)
#   timeout: 10              # Overall timeout for the entire crawling process (in seconds). Set to positive value to enable, -1 to disable
#   fetch_time: 10
#   navigation_timeout: 30
# Web search tool (uses InfoQuest)
#   search_time_range: 10

and a $VAR reference in the config is substituted verbatim from the environment
(AppConfig.resolve_env_variables() → os.getenv(...)), so the value that arrives can be a
string. The client then compares it with 0:

• infoquest_client.py:142-147 (fetch) — if self.fetch_time > 0:, if self.fetch_timeout > 0:
• infoquest_client.py:166 (web_search) — if self.search_time_range > 0:
• infoquest_client.py:333-335, :373 (image_search) — 1 <= self.image_search_time_range <= 365

timeout: $FETCH_TIMEOUT therefore raises TypeError: '>' not supported between instances of 'str' and 'int' out of the tool, and a blank timeout: (None) or an unset variable ("") does
the same. One mistyped line in config.yaml turns web_fetch, web_search or image_search
into a hard failure whose message points at the client instead of the config key.

What changed

From an operator's perspective, the InfoQuest timeouts now behave like the other providers':

• an integer, an integral float (3.0), or an integer-form string ("10", " 10 ", "-1", and
  therefore any $VAR substitution) is used as configured and reaches the request as an int;
• a boolean, a fractional value, a blank/non-numeric string, None or a wrong type falls back to
  the documented -1 (that filter is disabled) and logs
  Invalid InfoQuest timeout='off'; using default -1;
• an already-valid integer config produces a byte-identical request body.

Not touched: the model-visible tool schemas, image_size (a string option), the 30 s transport
timeout from #5782, and every other provider.

Surface area

• Agents / LangGraph — the web_fetch / web_search / image_search tool configuration
  path (deerflow.community.infoquest.tools). Only operator-owned config.yaml values move, and
  they now pass through one validation function before reaching the request builder.
• Default behavior change — for an already-invalid config the behaviour changes from
  "TypeError out of the tool" to "that filter is disabled and the rejected key is logged".
  Nothing changes for a valid config.

Bug fix verification

Test path: backend/tests/test_infoquest_config_timeout_coercion.py — six functions (19 cases)
that pin the values the tool hands to InfoQuestClient, plus two that pin the outbound crawl and
search bodies.

Did it go red on main and green on this branch? Yes.

Red on main (74f6dce4, these tests against the pristine infoquest/tools.py):

17 failed, 2 passed in 3.98s
test_string_timeouts_apply_to_every_configured_option[10-10]
  E   AssertionError: assert '10' == 10
test_env_string_timeout_reaches_the_crawl_request_as_a_number[asyncio]
  E   TypeError: '>' not supported between instances of 'str' and 'int'
      deerflow/community/infoquest/infoquest_client.py:144

The two that pass on main are the integer controls
(test_timeouts_reach_the_client_as_integers[10-10_1] and
test_configured_numbers_keep_their_meaning) — a config that is already an int is exactly
the case that must not change.

Green on this branch:

tests/test_infoquest_config_timeout_coercion.py                       19 passed in 4.11s
+ test_infoquest_client + test_infoquest_http_timeout + tavily + ddg_search + exa
+ serper + brave + image_search + jina_client + sofya + searxng_client
+ web_search_time_range
  411 passed in 19.64s

Offline: httpx.AsyncClient is patched in every async case, so no request left the machine.

Lint/format gate:

$ ruff 0.15.12 check backend/packages/harness/deerflow/community/infoquest/ backend/tests/test_infoquest_config_timeout_coercion.py
All checks passed!
$ ruff 0.15.12 format --check <same two paths>
2 files already formatted

A note on how this patch was prepared: it was written and measured by an automated agent
session working for the account owner, on Windows / Python 3.12. The numbers above are its own
measurements, reproduced on main and on this branch immediately before opening the PR; the
owner has not independently re-run them, so the human-attestation boxes in the template are
left for the owner to confirm rather than being ticked here.