fix: revert manual changelog update, as it should only be updated by CI/CD

CHANGELOG.md

@@ -1,26 +1,3 @@
-## Unreleased
-
-### BREAKING CHANGE
-
-- The stock `openai` client (no custom `api_base`) now defaults to the OpenAI Responses API
-(`/v1/responses`) instead of Chat Completions. Pin the old wire by adding `wire_api: chat` to the
-client block. Openai clients with a custom `api_base` and `openai-compatible` clients still
-default to `chat`; Codex OAuth always uses `responses` (`wire_api: chat` there is a config error).
-- Request patches are now wire-aware and chat-keyed patches never apply to the responses wire: if
-your stock openai client relied on `patch.chat_completions` blocks (or top-level model patches),
-migrate them to the sibling `patch.responses` key / the model patch's `responses:` sub-key
-(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.
-
-### 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
-- the responses wire always sends `include: ["reasoning.encrypted_content"]` and `"strict": false` tool definitions; strict third-party `/v1/responses` servers may reject these as unknown params when opted in via `wire_api: responses` (workaround: a `responses`-keyed client patch, e.g. `include: null` for Groq)
-
 ## v0.10.3 (2026-09-15)
 
 ### Feat