fix(telegram): suppress duplicate messages on high-latency streaming connections

[badgerbees]

Problem:

Users on slow or high-latency connections (particularly those using proxy chains like OpenRouter) were frequently seeing duplicate response messages. This occurred because GoClaw would fall back to a fresh sendMessage whenever the final "prettifying" edit of a streaming preview timed out or failed with a transient gateway error.

What Happens Now (after these changes):

1. Duplicate Suppression: When a final edit times out after reaching Telegram, the bot now knows to stop instead of sending a new message. The user will simply see the streaming preview (which already contains the final tokens) instead of an annoying second, identical message.
2. No More "Ghost" Messages: If the very first chunk of a stream times out but still lands on Telegram, the bot now flags it as a "ghost." During final delivery, it will skip the first part of the answer to ensure it doesn't repeat the ghost message's content.
3. Resilient Finalization: The bot now retries final edits 3 times. This makes the transition from "Drafting..." to the finalized response significantly more robust on flaky or high-latency networks.
4. Guaranteed Delivery: On short, single-chunk responses, GoClaw still prioritizes delivery over deduplication. If an edit fails definitely, it will still fall back to a fresh message to ensure the user never gets an empty response.

Technical Changes

1. Post-Connect Error Classification: Added isPostConnectNetworkErr to distinguish "Pre-connect" failures (safe to fallback) from "Post-connect" stalls (hazardous to fallback).
2. Ghost Message Signal: DraftStream tracks sendMayHaveLanded and passes a -1 placeholder to coordinate with the delivery layer.
3. Idempotent Edit Retries: editMessage now utilizes the retrySend wrapper to recover from Telegram's transient 5xx server downtime.