@LeonSGP43 Our custom plugin depend on this feature

Can you grant me permission to edit this branch?
I will help fix this issue

Verified this root cause independently on Windows 11 / Telegram DM delivery.

I reproduced the exact behavior this PR is addressing:

• live-adapter path delivered text only
• no native image attachment arrived
• direct Telegram Bot API sendPhoto with the same JPG worked, so the asset/platform were fine

The key local observation matched this PR direction:
_send_via_adapter() only called adapter.send(...) and ignored media_files in the live-adapter branch.

I validated the dispatch-style fix locally in a clean worktree with a focused regression test:

• added test_live_adapter_path_sends_image_attachment
• ran:
  pytest -q -o addopts='' tests/tools/test_send_message_tool.py -k 'live_adapter_path_sends_image_attachment or sends_text_then_photo_for_media_tag'
• result: 2 passed

I also checked the broader file on clean upstream main; it currently has an unrelated pre-existing failure in test_media_tag_outside_allowed_roots_is_not_sent, so the focused targeted pass is the honest verification signal for this bug.

Based on that repro, this PR is addressing a real user-facing regression, including Telegram (not just plugin-only edge cases).

I compared this PR with a separate local split of plugin send_message media routing work.

This PR looks like the better primary fix for #18422 because it covers the live-adapter path more broadly than my local variant: image, audio/voice, documents, and media-only sends.

A few follow-up hardening points from that comparison, in case useful:

• Check that a plugin adapter actually overrides the native media method being called, rather than falling through to BasePlatformAdapter behavior. That avoids accidentally degrading into local-path-as-text leakage.
• Preserve thread metadata for text + media sends when adapter media methods support metadata.
• For plugin platforms without a live gateway adapter, consider an explicit PlatformEntry.send_message_media or equivalent opt-in before passing media_files to a standalone sender. That keeps standalone plugins from receiving local paths unless they declared support.
• For unsupported media on text + media sends, a text-only delivery with a warning may be preferable to silently dropping the text or leaking paths.

I will not open a duplicate PR for the overlapping media-routing change; these are just possible follow-ups/gaps to consider here.