hermes - 💡(How to fix) Fix Gateway can resend a short fallback message when the real final Telegram response was already delivered [2 pull requests]

Summary

In Telegram gateway runs, the final answer can be delivered successfully, but the queued-follow-up path still treats delivery as unconfirmed and sends a small fallback response instead of trusting the real message.

Observed behavior

Logs for a Telegram run showed:

• Queued follow-up ... final stream delivery not confirmed; sending first response before continuing.
• then a tiny Sending response (5 chars) to 454202880

The real LT#315 summary was later delivered in a separate reprocessing pass, which suggests the original run misdetected delivery confirmation.

Root cause

gateway/run.py suppresses duplicate sends using:

• final_response_sent
• response_previewed
• final_content_delivered

But some successful final-send paths in gateway/stream_consumer.py do not consistently mark final_content_delivered=True, so the gateway thinks the final content was never confirmed.

Proposed fix

Ensure successful final delivery sets both:

• final_response_sent = True
• final_content_delivered = True

on all final-send paths, including fallback and cancellation cleanup.

Regression test

Add coverage for the case where:

• final_response_sent=False
• final_content_delivered=True
• response_previewed=False

and assert the gateway suppresses the resend.