fix(channels): keep Telegram polling after a bad getUpdates batch

[cursor]

Bug and impact

Telegram getUpdates could stall the channel permanently, so later user messages were never delivered.

Two concrete triggers:

1. The request omitted limit, so Telegram returned up to 100 updates. write_cb rejects bodies over 256 KiB. A backlog of long messages (for example while an agent turn is in progress) makes curl abort with a write error. tg_poll then returns without moving last_update_id, and every later poll retries the same batch.
2. A message with no numeric from.id (channel posts and some anonymous-admin messages) made parse_update return -1. The poll loop does not advance the offset on that error, so that update stayed at the head of the queue and blocked everything after it.

Root cause

src/channels/telegram.c tg_poll / parse_update: the client consumed only result[0] but accepted the API's 100-update default, and structural skips were reported as hard failures that leave the offset unchanged.

Fix

• Request limit=1, which matches the single-update parser and keeps each body well under the 256 KiB cap.
• Treat a message with no sender id as a skip (return 0) after recording its update_id, so the next poll fetches the following update.

Validation

make test_telegram failed on the new cases before the fix (missing from still returned -1, and the getUpdates URL had no limit=1) and passes after it: 42 tests, 0 failed.