feat(telegram): support non-image document attachments (PDF/DOCX/etc.)

[Austin5925]

Summary

Adds non-image document attachment support to the Telegram bridge. Previously
PDFs/DOCX/TXT/ZIP files sent to a CodePilot Telegram bot were either silently
dropped (single message) or caused inconsistent failures (mixed album with
images), making the Telegram bridge unable to handle anything but images.

Closes #539

What was broken

The inbound dispatch (telegram-adapter.ts:551-600) only recognized photos
and image-MIME documents:

const hasPhoto = m.photo && m.photo.length > 0;
const hasDocImage = m.document && this.isDocumentImage(m.document);
const hasMedia = hasPhoto || hasDocImage;

Non-image documents fell into the // Unhandled message type — skip branch
at line 597 with no enqueue, no error, no acknowledgment. The album path
(flushMediaGroup, line 791-805) similarly ignored non-image documents.

CodePilot's main chat UI input already supports file attachments (per #11
and PR #508), but the Telegram bridge adapter is a separate code path that
had not been updated.

What this PR does

1. Single-document path: new processSingleDocumentMessage() mirrors
   processSingleImageMessage(), downloads the file, and enqueues with the
   original filename + Telegram-reported MIME.
2. Mixed-media album path: flushMediaGroup now iterates documents in
   addition to photos/image-docs, with separate counts in the audit summary.
3. Refactor: downloadFileById is parameterized (mimeOverride,
   nameOverride, mimeFallback, nameFallback, kind) so all three
   paths share a single implementation. Photo and image-doc paths preserve
   their existing behavior; non-image docs use doc.file_name and
   doc.mime_type directly so Claude can recognize the file format.
4. Settings (mirror existing image_ pattern)*:
   • bridge_telegram_document_enabled (default true)
   • bridge_telegram_max_document_size (default 20 MB — Telegram Bot API limit)

The downstream attachment pipeline (claude-client.ts:1037-1048) already
handles non-image files end-to-end — they're written to .codepilot-uploads/
and Claude is prompted to read them via its Read tool. No changes needed
there.

Test plan

• npm run typecheck — clean
• npm run test — 1143/1143 passing
• npx eslint src/lib/bridge/adapters/telegram-adapter.ts src/lib/bridge/adapters/telegram-media.ts — no new warnings (only pre-existing _chatId/_draftId unused-param warnings on line 325, unrelated to this change)
• Manual reproduction (please verify):
  • DM bot a .pdf → bot should reply with content analysis
  • DM bot an album of [image, pdf] → bot should reply analyzing both
  • DM bot a 25 MB file → bot should reply "File too large (25.0 MB, limit 20 MB)."
  • DM bot a .png (regression) → still works as before
  • Set bridge_telegram_document_enabled=false → docs with caption fall through to text-only path; docs without caption silently skip (matches old behavior for unsupported types)

Notes

• Discord adapter has the same limitation (discord-adapter.ts:509 filters
  for image/* only). Out of scope for this PR — happy to file separately.
• Voice/audio support (Telegram bridge doesn't support audio input (Telegram 不支持语音输入) #130) and video are still unhandled — separate PRs.
• The "An unexpected error occurred" symptom mentioned in bug(telegram): non-image document attachments are silently dropped or trigger "unexpected error" #539 appears to
  come from a downstream code path triggered by mixed-media albums; routing
  documents through the proper enqueue path eliminates the symptom in
  testing on main HEAD.

[vercel]

@Austin5925 is attempting to deploy a commit to the op7418's projects Team on Vercel.

A member of the Team first needs to authorize it.