fix(routing): offered tools must not make a local model unroutable

Verified against a real Open WebUI container: it attaches its ~26 built-in
tools (knowledge bases, notes, calendar, ...) to every single message, and
resolve() treated that offer as a hard capability requirement. On a pool of
tools-less local models a plain "hello" therefore failed with "No healthy
model available that satisfies required capabilities", and a pinned local
model was reported as "not available - not in the pool (deleted?)".

In the OpenAI contract `tools` is an offer; only tool_choice: "required" (or
a named function) makes the call impossible without them. Keep preferring a
tool-capable model, but fall back to serving the request with the tools
stripped - together with tool_choice/parallel_tool_calls, which a provider
rejects on their own. A pin whose only shortcoming is tool support is now
honoured; an unknown pin and tool_choice: "required" still fail loudly.

The downgrade is never silent: X-Cortiq-Tools-Dropped: true, plus
cortiq.tools_dropped in the echo block.

docs/PROTOCOLS.md

@@ -65,6 +65,13 @@ concatenated, images and other non-text parts are skipped); `tools` may be `null
 cannot be read comes back as an OpenAI error envelope with HTTP 400 — never a bare 422,
 which OpenAI clients cannot parse (they show no answer at all).
 
+`tools` is treated as an **offer**, not a requirement. The gateway prefers a tool-capable
+model, but when none is available it answers without the tools rather than failing, and says
+so via `X-Cortiq-Tools-Dropped: true` (chat UIs attach their built-in tools to every message,
+so the strict reading made ordinary chat impossible on a tools-less local pool).
+`tool_choice: "required"` — or a named function — is a real requirement and still fails with
+`502 no_healthy_model` when no model can honour it.
+
 ### Response (non-streaming)
 
 ```jsonc