fix: stream attachment handling in workers (#12870)

We’ve been watching Sidekiq workers climb from ~600 MB at boot to
1.4–1.5 GB after an hour whenever attachment-heavy jobs run. This PR is
an experiment to curb that growth by streaming attachments instead of
loading the whole blob into Ruby: reply-mailer inline attachments,
Telegram uploads, and audio transcriptions now read/write in chunks. If
this keeps RSS stable in production we’ll keep it; otherwise we’ll roll
it back and keep digging

rubocop/attachment_download.rb

@@ -0,0 +1,17 @@
+require 'rubocop'
+
+module RuboCop::Cop::Chatwoot; end
+
+class RuboCop::Cop::Chatwoot::AttachmentDownload < RuboCop::Cop::Base
+  MSG = 'Avoid calling `.file/.blob.download`; use `blob.open` or streaming IO instead.'.freeze
+
+  def_node_matcher :unsafe_download?, <<~PATTERN
+    (send (send _ {:file :blob}) :download ...)
+  PATTERN
+
+  def on_send(node)
+    return unless unsafe_download?(node)
+
+    add_offense(node.loc.selector, message: MSG)
+  end
+end