fix(telegram): accept image files delivered as application/octet-stream

[vinceferro]

Problem

On iOS, Send as File is the only way to share a photo at original quality. Telegram delivers it as a document with mime_type=application/octet-stream and no preview — the filename extension (.jpg) is the only type hint.

handleDocumentMessage routes on mimeType.startsWith("image/") (fast path) or the DOCUMENT_MIME_TYPES allowlist. An octet-stream .jpg matches neither, so iPhone users get the unsupported-document reply and cannot send images as files at all.

Repro

1. iPhone → bot chat → pick photo → Share → Send as File (keep quality)
2. Add a caption, send
3. Bot replies that the document type isn't supported; nothing reaches the model

Fix

When mime is not image/*, fall back to the filename extension (.jpg/.jpeg/.png/.webp/.gif). If it looks like an image: normalize the file part's mime and data-URI prefix to the real type, and reuse the existing image-input capability check. Documents with proper image/* mimes keep the existing path unchanged.

Verification

Tested end-to-end against a live opencode serve with an octet-stream-delivered jpg:

	result
before	rejected as non-document; never reaches the model
after	part arrives as image/jpeg, model describes the image correctly

[Document] Sending image document (82686 bytes, IMG_5548.JPG, image/jpeg)

Happy to adjust the extension list or move the fallback into the existing fast-path branch if maintainers prefer that shape.

[grinev]

@vinceferro thanks for the PR.
Could you please fix two issues before merge:

Major: src/bot/handlers/document-handler.ts:157-162 always uses image/jpeg for extension-based fallbacks. PNG, WebP, and GIF files are
therefore sent with an incorrect MIME type and data URI, although their bytes are unchanged. Please map each supported extension to
its actual MIME type.

Major: src/bot/handlers/document-handler.ts:138-171 applies the filename fallback to every non-image MIME type before the known
document MIME check. For example, a PDF named report.png is routed as an image and may be rejected when the model does not support
images. Please restrict the fallback to generic MIME types such as application/octet-stream, while preserving the priority of known
document MIME types.

Please also add tests for octet-stream JPEG/PNG/WebP/GIF files and for MIME-type precedence with a PDF named with an image extension.