fix: support Buffer/stream/path uploads in editMessageMedia (#1189)

[yagop]

Problem

editMessageMedia could only upload a new file when media was passed as attach://<local-path>. A Buffer / stream, or even a plain local path, was unsupported (the field was typed string), and the secondary fields (thumbnail / cover) were string-only. Every other send method accepts a Buffer/stream/path, so this was an inconsistency.

Refs #1189

Fix

Route media through the same _buildMediaItems pipeline used by sendMediaGroup / sendPaidMedia:

• The primary media and its thumbnail / cover now accept a Buffer / stream / local path (uploaded as an attach:// multipart part) or a file_id / URL string (passed through).
• media is widened from InputMedia to Uploadable<InputMedia> (the existing helper that widens file fields to InputFile).
• _buildMediaItems's parameter type is broadened to also accept Uploadable<InputMedia>.

// Now works (previously a type error / unsupported):
await bot.editMessageMedia(
  { type: 'photo', media: fs.readFileSync('new.png') },
  { chat_id, message_id },
);

Non-breaking

• string callers are unaffected (string is assignable to InputFile).
• The legacy attach://<local-path> form is still accepted (the prefix is stripped and the path uploaded).
• file_id / URL callers still produce a urlencoded body (no multipart).

Tests / verification

• npm run typecheck clean; npm run build clean.
• Unit (test/unit/telegram.test.ts): 45/45 pass, incl. 3 new (Buffer -> attach://0_media; video thumbnail Buffer -> attach://0_thumbnail; file_id -> urlencoded passthrough).
• Live API: editMessageMedia scoped run = 3/3 pass (attach:// path, Buffer upload, file_id with caption + reply_markup).
• Regenerated doc/api.md; corrected a now-stale sendMediaGroup doc comment that claimed editMessageMedia's secondary fields were string-only.

🤖 Generated with Claude Code

[danielperez9430]

LGTM