fix(api_fetch): accept REST-natural shapes for url / params / body

[AdarshGoel2001]

Summary

api_fetch's URL/argument plumbing currently produces silent failures when
agents use the natural REST/curl idiom rather than the bench's strict
"separated URL + JSON-stringified body" convention. Two related symptoms,
one root cause (the tool surface advertises a narrower contract than the
underlying impl actually supports). This PR widens the contract on both
the URL side and the params/body side, so the bench evaluates whether the
agent can do the workflow, not whether the agent has memorised the
formatting convention.

Why this matters

The "URL goes here, params go separately, body is a JSON-stringified
string" convention is bench-specific scaffolding — it appears in the
api_fetch tool description and in api_search results, but is otherwise
absent from pretraining. The natural shapes (query inlined in URL; body
as a plain object) dominate REST docs, curl examples, fetch/axios usage,
SDK tutorials, and so on. Frontier models pick up the convention from the
tool description and hold it; smaller / cheaper models default to the
natural shape and slip.

When that happens the failure modes are silent and demoralising — the
agent has typically already done the multi-hop research correctly and only
fails on the write call. From the maintainer's perspective the bench
stops measuring agent capability and starts measuring API-protocol pedantry.

What changes

1. Query strings inlined in the URL

Before: api_fetch("GET", ".../messages?q=from:Jordan") 404s because the
trailing ?q=… survives _url_to_internal_path's prefix-stripping and
the per-app route handlers match by exact path string.

After: a new _merge_url_query_into_params(url, params) helper lifts any
inlined query string out of the URL into the parsed params dict before
routing. URL-decoded; repeated keys preserved as a list; caller-supplied
params win on conflict.

Pre-fix observation (claude-haiku-4-5 via Claude Code subscription harness):
  api_fetch GET https://gmail.googleapis.com/gmail/v1/users/me/messages?q=…
    �� {"error":{"code":404,"message":"No handler for GET ...?q=…"}}
  api_fetch GET https://*.salesforce.com/services/data/v60/query?q=SELECT…
    → {"error":"Missing query parameter 'q'"}

2. Dict-shaped params and body

Before: api_fetch(..., params: Optional[str], body: Optional[str]) →
LLM-facing tool wrappers (OpenAI tool schema, FastMCP, etc.) advertise a
string-only schema. Loose validators (chat-completions APIs) usually
serialize dicts through to _coerce_to_dict invisibly. Strict validators
(MCP stdio clients, e.g. Claude Code) reject the call client-side before
it reaches api_fetch — the agent never sees the result, eventually
gives up with "I'm experiencing a technical issue with JSON body
parameter formatting."

After: annotations widened to Union[dict, str, None]. The advertised
schema becomes anyOf: [object, string, null]. The impl is unchanged
because _coerce_to_dict already accepts both shapes. The documented
"happy path" stays JSON-stringified — api_search results still model
that shape, no prompt-side tightening — so models trained against the
previous tool description continue to work unchanged. This is purely
tolerance-side.

Pre-fix observation (same harness):
  api_fetch PATCH .../sobjects/Contact/003001  body={"Phone":"+1-555-0101"}
    → silently rejected at the MCP client boundary; never logged,
      never executed, never surfaced as an error to the agent

Tests

• TestMergeUrlQueryIntoParams — 6 unit tests (no-query passthrough,
  query-only-in-URL, URL-decoding, query+params merge, conflict
  resolution, repeated keys).
• TestApiFetchAcceptsQueryInUrl — 2 end-to-end regression guards
  (Gmail messages list, Salesforce SOQL query) confirming both call
  styles route equivalently.
• TestApiFetchAcceptsRestNaturalShapes — 3 tests covering dict
  params, dict body, and a signature-shape regression test that
  fails fast if someone tightens the annotations back to Optional[str]
  (so the strict-MCP-client path doesn't silently break again).

Full existing suite (638 tests under tests/) passes. Pre-existing
unrelated import errors in tests/tools/test_*.py (which import
automationbench.tools.salesforce rather than the actual
automationbench.tools.zapier.salesforce) are present on main and
unaffected by this change.

Non-goals

• No change to the documented happy path. Tool descriptions, api_search
  result shapes, and _coerce_to_dict's behaviour are all unchanged.
  Strings remain the preferred form.
• Doesn't widen method or url, only the two args where the dict-vs-string
  ambiguity actually surfaces in observed agent behaviour.

Why a single PR

Both halves are the same family of fix: an LLM-facing schema/contract
narrower than the impl actually supports, causing silent rejection of
the natural agent-output shape. They share the test file, the same
underlying observation (smaller models slip on bench-specific convention),
and the same justification. Reviewing them together keeps the framing
coherent.