docs(mcp): audit mcp-* tool docs against current implementation

[jfallows]

Summary

Follow-up to #419: a systematic audit of the mcp-* binding reference docs (as they'll stand once #419 merges) against the actual current zilla implementation on its develop branch, focused on the tools sections for each binding that has tools. This branch was based on #419's tip and has since been rebased onto support/2.x post-merge, so its diff is scoped to audit fixes only.

Every finding below was verified directly against origin/develop source in the zilla repo (OpenAPI spec JSON, config classes, the composite generator, K3PO specs) before being fixed — not taken on faith from an initial pass.

Fixes

• mcp-kafka: binding-mcp-kafka renamed its tool constants (produce → produce_message, consume → consume_messages) after these docs were written. Fixed in tools.md/routes.md/options.md/client.yaml. Every other mcp-kafka tool name already matched.
• mcp-openapi: fixed a broken cross-link to mcp-kafka-connect/mcp-schema-registry in the x-zilla-mcp callout — @include'd partials resolve relative links from the partial file's own path (mcp-openapi/.partials/), so reaching a sibling binding directory needs two ../, not one. This was failing the linkChecker CI job.
• mcp-openapi: resources.description has no fallback to the operation's native description/operation id (unlike tools.description) — corrected the doc, which claimed a fallback chain McpOpenapiCompositeGenerator doesn't implement.
• mcp-openapi: removed when[].capability from routes.md — no such field exists on McpOpenapiConditionConfig, and the JSON schema patch would reject it outright (additionalProperties: false).
• mcp-http: documented tools.title and tools.annotations (with its 4 hint fields) — both exist and are fully wired in McpHttpToolConfig/McpHttpOptionsConfigAdapter but were never written up.
• mcp-kafka-connect / mcp-schema-registry: corrected required/optional status for every request-body-derived tool argument (7 fields across 6 tools). Neither bundled OpenAPI spec declares a JSON-Schema required array on any request body, and McpOpenapiCompositeGenerator only required-flags a body property when one exists — so these arguments are actually optional in the generated tool, despite being documented as required.
• mcp (base): eager.policy's none/all semantics were exactly swapped in the docs. none (the default) disables cache partitioning entirely, so every tool stays eager; all marks every tool cold. Confirmed against McpProxyCache.eager()/eagerConfigured() and the binding's own K3PO specs (cache.serve.tools.list.eager.{none,all,explicit}).

Verification

• pnpm lint — zero new violations.
• pnpm link-checker (full VuePress build + lychee-equivalent local check) — 0 errors, confirming the mcp-openapi link fix.

Known pre-existing CI gap (not fixed here, out of scope)

schemaChecker fails on this branch, but the drift it reports spans the entire binding catalog — amqp, asyncapi, kafka, kafka-proxy, mqtt, openapi, several vaults/guards, and mcp all show the same "missing prompts[].name-style fields entirely" pattern. .check-schema/zilla-schema.json is a point-in-time snapshot (per this repo's own CLAUDE.md, it needs periodic regeneration from a live Docker container) and is stale well beyond anything this PR touches. Fixing it would mean regenerating that snapshot against a live Zilla build and reconciling the whole reference tree — a separate, much larger effort, not a side effect of an mcp tools audit. Confirmed this isn't something introduced by this diff: the same failure mode reproduces locally with pnpm check-schema on this branch.

Test plan

• pnpm lint
• pnpm link-checker (local)
• pnpm check-schema — fails on pre-existing, repo-wide schema drift unrelated to this PR (see above)
• Visual check via pnpm dev (not run in this environment)