[codex] fix Telegram uploads and repeated progress edits

[GSL-R]

What changed

• routes Node streaming and multipart bodies through node-fetch instead of JSON-stringifying them in the IPv4 Telegram fetch adapter
• keeps the existing IPv4 HTTPS agent for file uploads
• consumes each pending Telegram tool-status snapshot exactly once
• adds focused tests for Node Readable uploads and status update coalescing

Root cause

The custom IPv4 fetch adapter only handled strings and JSON-compatible bodies. grammY builds file uploads as a Node Readable multipart stream, so sendPhoto was serializing that stream as JSON and failing with a network-style error.

Separately, the Telegram tool-status updater never cleared pendingStatusText after a successful flush. Its finally block therefore scheduled the same editMessageText forever during long agent runs, generating unnecessary Telegram traffic and delaying real deliveries.

Impact

• sendPhoto, sendDocument, and sendVoice can retain their multipart bodies
• long-running tasks no longer continuously resend an unchanged tool-status message
• ordinary JSON Telegram calls continue to use the existing IPv4 adapter

Validation

• npx tsc
• 17 focused Telegram tests passed
• live sendPhoto through /api/channel/send succeeded with the generated dream image after restart

[lidge-jun]

Reviewed against current dev (c7891ae): the diff applies cleanly, tsc --noEmit passes, and the new fetch-body / status-buffer tests pass. Two notes before marking ready:

1. requiresStreamingFetchBody matches body.constructor?.name against exact class names (Readable, FormData, …). If grammY ever hands over a subclass of Readable (e.g. a custom multipart stream class), the name check misses it and the body falls back to JSON.stringify, reintroducing the original bug. Consider body instanceof Readable || typeof body.pipe === 'function' || typeof body.getReader === 'function' style duck-typing instead of constructor names.
2. node-fetch@3 does not accept a WHATWG ReadableStream as RequestInit.body (it supports Node streams, Blob, FormData). The ReadableStream entry in the allow-set would route such a body to node-fetch only to fail there — either drop it or convert via Readable.fromWeb() first.

Neither blocks the grammY Readable path verified live, so this is ready-adjacent — happy to merge once addressed or consciously accepted.

[GSL-R]

Addressed both review notes in 642e85e:

• replaced constructor-name matching with FormData/Blob instanceof checks plus Node stream pipe() duck-typing, including a custom Readable subclass regression test
• removed WHATWG ReadableStream from the native node-fetch path and added a negative test

Local verification:

• telegram fetch-body + status-buffer tests: 4/4 passed
• npm run typecheck: passed

The refreshed PR Actions run currently fails in 12 unrelated prompt-size, AGY quota, quota API, and shared-skill assertions. The latest upstream main runs are failing in the same period as well; the Telegram tests pass in this PR run.