v0.11.1

Added

• The Baileys engine now honors the per-session egress proxy (#859). proxyUrl — http, https,
  socks4 or socks5, credentialed form included — is applied through a Node-layer agent on both the
  WhatsApp WebSocket and media up/downloads (https-proxy-agent / socks-proxy-agent, now direct
  dependencies). Previously the engine warned baileys_proxy_unsupported and connected direct,
  silently exposing the host's real egress IP for exactly the deployments that configured a proxy.
  An unusable proxy value now fails the session start instead of falling back to a direct
  connection. Credentials authenticate on the socket itself, so the Chromium first-CONNECT 407
  limitation that can bite the wwjs engine's proxy-auth path does not apply to this engine.

• The OpenAPI spec now declares a templated default server. servers was empty; it now carries
  http://{host}:{port} with localhost/2785 defaults, so Swagger UI's "Try it" works out of the
  box and stays usable on real deployments via the host/port variables, and static consumers of the
  published openapi.json get a concrete base URL to display.

Fixed

• The published OpenAPI spec no longer advertises a 200 the catalog endpoints never return.
  GET /sessions/{id}/catalog, /catalog/products and /catalog/products/{productId} each declared
  a 200 response described as "always null on whatsapp-web.js", from a time when that engine
  returned an empty result instead of refusing. Both adapters now throw, so every call answers 501,
  and a generated client built against the old snapshot modelled a success case that cannot occur.
  The stale declarations are removed, the remaining 501 description no longer names only Baileys,
  and openapi.json is regenerated.

• The documentation set now matches the shipped implementation. Every numbered document was
  checked claim by claim against source, and the corrections concentrate where following the docs
  could fail silently. Session auth was documented at ./data/.wwebjs_auth when it lives under
  SESSION_DATA_PATH (default ./data/sessions), so every backup, server-transfer and rollback
  procedure copied a directory that does not exist and still reported success; compose commands
  addressed a service named openwa where the shipped file defines openwa-api; the upgrade runbook
  used docker compose pull against a compose file that builds from source; health checks omitted
  the global api prefix; and several referenced files and scripts were never part of the repository.
  Documented settings that the configuration layer does not read (WA_RECONNECT_INTERVAL,
  STORAGE_S3_*, CACHE_TYPE, API_PREFIX and others) are replaced by the real names. Endpoints
  and tooling that do not exist — per-session export/import, a 1.x upgrade path, an MCP tool name —
  are removed, the catalog endpoints are marked as answering 501 on both engines, and the glossary no
  longer defines a message queue, message scheduling or a Redis-backed dead-letter queue, none of
  which the gateway has. Two risk-register rows that claimed send-rate safeguards now describe the
  controls that ship. Structurally, docs/23-plugin-sandboxing.md becomes docs/30, resolving a
  duplicate prefix; the engine capability matrix joins the sequence as docs/29; a language-forked
  second copy of the Docker guide is removed; and the index lists all thirty documents. Separately,
  the community guidelines and the incident-response template both published a security contact
  address that does not exist, so a vulnerability report sent by either route reached no maintainer;
  both now carry the channels SECURITY.md defines, GitHub Security Advisories first.

• A source install without the GNU patch binary no longer silently ships an unpatched
  whatsapp-web.js. OpenWA backports the fix for the WhatsApp Web 2.3000.x message-id rename during
  npm install; when the patch binary was missing — the default on Windows outside Git Bash — the
  install printed one warning, exited successfully, and left whatsapp-web.js broken. The failure then
  surfaced only in production, as sends returning the engine returned no message despite delivering,
  and chat, media and typing operations throwing the minified r: r. The backport now falls back to
  git apply, which every source install has by definition and which produces a byte-identical tree.
  With neither applier present the install still degrades rather than failing, so a Baileys-only setup
  is unaffected — but the whatsapp-web.js engine now logs an explicit, actionable error at session
  start instead of failing opaquely later. Prerequisites and a troubleshooting entry are documented.

• The release runbook in docs/15 now describes the process the repository actually uses. §15.7
  documented a release-branch-and-PR flow with a generic pre-release checklist; releases are in fact
  cut as a single chore(release) commit on main plus an annotated v* tag, with everything from
  the multi-arch build through promotion, anonymous publish verification and the GitHub Release
  handled by release.yml. The section now carries the exact four-file commit, the gate commands to
  run locally beforehand, what the pipeline does with the tag, how to recover from a failed gate
  (nothing is published before promote, so the tag can be moved), and the post-release checks —
  including doing the registry checks logged out.