Fix TelegramBotHandler swallowing errors on non-JSON responses (#2026)

[Pablo1Gustavo]

Fixes #2026

What it solves

TelegramBotHandler::sendCurl() was silently swallowing errors whenever the Telegram API or an upstream proxy returned a non-JSON body (Cloudflare 502 pages, Nginx error pages, truncated responses, etc.). json_decode() returned null, the guard $result['ok'] === false evaluated to false (since null === false is false), and no exception was raised — log records were lost during the exact infrastructure outages where alerting matters most.

How it solves

• After json_decode(), reject anything that isn't a JSON object via \is_array($result), throwing a RuntimeException with a clear "Unexpected non-JSON response" message.
• Replaced $result['ok'] === false with ($result['ok'] ?? null) !== true. This also catches valid JSON responses that simply lack the ok key (e.g. proxy-injected error envelopes), which the old check would silently accept.
• Fall back to "Unknown error" when description is absent, preventing the previous undefined-key warning.
• Extracted the response validation into validateApiResponse() so each failure mode can be tested without a live HTTP call.

Tests

Added a data-provider-driven test covering all six failure paths (curl failure, HTML body, empty body, ok:false with/without description, missing ok key) plus a happy-path assertion. The existing tests continue to pass.