[aZuiZui]

Some of my older files have a part Telegram won't serve any more: every chunk comes back as -503 Timeout, or the message is gone. In 2.x the stream has already written 206 and the headers by then, so the client gets an empty body that just ends. rclone treats it as a short read and keeps retrying, and the log only says context deadline exceeded.

This PR:

• reads the first 64 KiB before writing the status line. If that read fails, the response is 502 (telegram_part_unavailable for a -503 or a missing message, telegram_read_failed otherwise) and api.stream_unreadable is logged with the file id. Errors that already have their own status (504 etc.) keep it.
• does the same when opening the file fails because a part's size had to be looked up and the message is gone (older uploads without stored sizes). That was a 500.
• keeps the Telegram error when the retry middleware's deadline runs out while it's retrying a -503. It now reads as rpc error code -503: Timeout (retried until the deadline) and still matches errors.Is(err, context.DeadlineExceeded) and tgerr.As.
• adds the message id to the part errors, so the log says which message is broken.

Normal streams only change in that the first 64 KiB are read before the headers go out.

Tested with unit tests for the stream handler and the retry middleware, and with go test -race -tags=integration for api, telegramstore and transfer. I also tried it on a test instance by pointing a part at a message that doesn't exist: before it was a 500 (or an empty 206), now it's a 502 every time, and the file reads normally again once the part is fixed.