docs: clarify timeout-vs-retry behavior and retry headers for API Request Tool

[stephenvapiai]

Clarifies two recurring API Request Tool reliability questions on the existing "Handle API Request tool latency and retries" page.

[stephenvapiai]

Why this change

Recurring customer confusion about API Request Tool retry/timeout behavior, evaluated via the Enterpret Context Graph over the last 7 days vs. the prior 7 days and a trailing 28-day baseline (customer-facing sources: Plain support tickets, Fern Ask AI conversations, Discord, Posthog NPS).

• 9 distinct customer conversations this week, 22 more in the prior 3 weeks, asked about backoffPlan / timeoutSeconds / excludedStatusCodes for the API Request Tool — a sustained, recurring pattern rather than a one-off spike.
• Two specific sub-questions came up repeatedly and are not answered by the existing "Handle API Request tool latency and retries" page:
  1. Whether a request that times out with no response (vs. a received non-2xx response) is treated as retryable under backoffPlan.
  2. What request headers accompany a retry attempt vs. the original request.
• The existing /observability/logs/webhook-logs page corroborates that this is a genuinely open question in the docs today: it states a long request duration "can indicate retries or a timeout, but does not prove either one by itself," rather than defining the relationship.

Classification: Incomplete content — the page covers backoffPlan/timeoutSeconds/excludedStatusCodes well for the non-2xx-response case, but doesn't address the timeout-with-no-response case or retry-attempt headers.

What this PR does

• Adds a new "Timeouts versus retries" section stating what's confirmed from the schema (retries are defined in terms of HTTP status codes on a received response) and explicitly flagging the two unconfirmed behaviors as open questions, with cross-links to Webhook logs and support.
• Does not assert a specific timeout-retry or retry-header behavior that isn't already confirmed in the docs/schema — both open items are left as explicit <!-- TODO (docs team) --> comments for the docs team to confirm with engineering and then finalize, per the customer-quote/evidence-integrity rule against fabricating unverified product behavior.

Scope note: Per the current run's candidate filter, security/auth/authorization/privacy/regulatory/compliance topics were explicitly excluded from consideration this run. This gap (HTTP retry/timeout mechanics for the API Request Tool) does not touch any of those categories.