feat: accept future Captain response payloads (#15212)

This is phase one of a rolling deployment for Captain burst handling.

The job now accepts an optional third argument named
`responding_to_message_id`. The job does not use the argument yet, and
no enqueue call changes in this PR. The change lets old workers accept
the future three argument payload while versions overlap during
deployment.

There is no behavior change.

This is a pre-requisite for
https://github.com/chatwoot/chatwoot/pull/15133 because if we introduce
another argument, and post deployment, older jobs will fail with
argument error and result in no captain replies

## Validation

* `bundle exec rspec
spec/enterprise/jobs/captain/conversation/response_builder_job_spec.rb`
* `bundle exec rubocop
enterprise/app/jobs/captain/conversation/response_builder_job.rb`

enterprise/app/jobs/captain/conversation/response_builder_job.rb

@@ -7,7 +7,7 @@ class Captain::Conversation::ResponseBuilderJob < ApplicationJob
   retry_on ActiveStorage::FileNotFoundError, attempts: 3, wait: 2.seconds
   retry_on Faraday::BadRequestError, attempts: 3, wait: 2.seconds
 
-  def perform(conversation, assistant)
+  def perform(conversation, assistant, responding_to_message_id = nil) # rubocop:disable Lint/UnusedMethodArgument
     @conversation = conversation
     @inbox = conversation.inbox
     @assistant = assistant