feat(TASK-057): web_search_coyote works on both OpenAI wire APIs

- openai searches run an attempt chain: the chat-completions mechanism
  (search-preview model + web_search_options patch) first, then the
  Responses-native web_search tool on a responses-capable model; the
  search fails only when both attempts fail
- both wire-keyed patches (COYOTE_PATCH_OPENAI_CHAT_COMPLETIONS /
  COYOTE_PATCH_OPENAI_RESPONSES) are exported per attempt; the client's
  resolved wire applies exactly one
- supports_native_search accepts responses-capable openai families
  (gpt-4o*/gpt-4.1*/gpt-5*/o3*/o4*)
- stub-coyote harness pins attempt order, patch export, model mapping,
  hard failure, and untouched non-openai paths
  (scripts/test-web-search-tool.sh)
- CHANGELOG: responses-default breakage caveat replaced with the
  both-wire feature note

CHANGELOG.md

@@ -12,12 +12,10 @@ migrate them to the sibling `patch.responses` key / the model patch's `responses
 (env override: `COYOTE_PATCH_<client>_RESPONSES`).
 - Sessions saved after this change may contain the new `reasoning` thinking blocks (encrypted
 reasoning items from the Responses API); older coyote binaries cannot load those sessions.
-- OpenAI native web search (the bundled `web_search_coyote` tool) uses the chat-only
-`gpt-4o-*search-preview` mechanism, which the responses wire does not serve: until the tool is
-updated, pin `wire_api: chat` on the openai client when relying on it.
 
 ### Feat
 
+- the bundled `web_search_coyote` tool serves openai native web search on both wires: it tries the chat-completions mechanism (the chat-only `gpt-4o-*search-preview` models + `web_search_options`) first and falls back to the Responses-native `web_search` tool on responses-capable models (`gpt-4o*`/`gpt-4.1*`/`gpt-5*`/`o3*`/`o4*`), failing only when both attempts fail — the stock responses default needs no `wire_api: chat` pin
 - support `wire_api: responses | chat` on the openai and openai-compatible clients, with wire-aware request patching on both patch layers
 - report token usage (including cached input tokens) on the openai responses path
 - streaming responses that end with `response.incomplete` now surface the truncation reason (e.g. `max_output_tokens`) when no visible output (text or tool calls) was delivered — matching the non-streaming behavior — and record token usage for truncated turns instead of ending silently