fix: Telegram final flush silently drops rate-limited response chunks

[sam-saffron-jarvis]

What changed

• Added a context-aware final Telegram delivery path that waits for the existing edit interval before flushing completed response chunks.
• Final edits and continuation placeholders now retry bounded transient failures, including Telegram 429 responses, while honoring retry_after when supplied.
• Final delivery is capped at three attempts and a 30-second deadline. If all attempts fail, streamReply persists the completed turn but returns an error instead of silently reporting success.
• Updated the long-response test with a rate-limiting sender that injects a 429 and rejects edits sent too close together, then verifies every chunk is delivered in order.
• Added a permanent edit-failure test proving incomplete final delivery is surfaced to the caller.

Why this is high-value

Telegram streaming is a daily Jarvis path. Fast completions and long answers previously forced final edits back-to-back, bypassing the normal three-second edit pacing. A single flood-control or transient failure could leave Telegram showing truncated text or stale progress even though the complete answer was persisted and the turn returned success. The bounded paced retry closes that user-visible reliability gap without changing provider streaming or transcript behavior.

Validation

• gofmt -w internal/serve/telegram.go internal/serve/telegram_test.go
• go build ./...
• HOME=<clean temp dir> XDG_CONFIG_HOME=<clean temp config> CODEX_HOME=<clean temp codex> GOPATH=/home/agent/go GOCACHE=/home/agent/.cache/go-build go test ./...
• git diff --check