### Apache Airflow version

main (development)

### What happened

The DataprocCreateBatchOperator (Google provider) handles the case when a batch_id already exists in the Dataproc API by 'reattaching' to a potentially running job.  

Current reattachment logic uses the non-deferrable method even when the operator is in deferrable mode.  

### What you think should happen instead

The operator should reattach in deferrable mode. 

### How to reproduce

Create a DAG with a task of DataprocCreateBatchOperator that is long running.  Make DataprocCreateBatchOperator deferrable in the constructor.  

Restart local Airflow to simulate having to 'reattach' to a running job in Google Cloud Dataproc. 

The operator resumes using the running job but in the code path for the non-derferrable logic.  

### Operating System

macOS 13.4.1 (22F82)

### Versions of Apache Airflow Providers

Current main.

### Deployment

Official Apache Airflow Helm Chart

### Deployment details

_No response_

### Anything else

_No response_

### Are you willing to submit PR?

- [X] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

"""Callback for when the trigger fires.
        This returns immediately. It relies on trigger to throw an exception,
        otherwise it assumes execution was successful.
        """
        if event is None:
            raise AirflowException("Batch failed.")
        batch_state = event["batch_state"]
        batch_id = event["batch_id"]
        if batch_state == Batch.State.FAILED:
            raise AirflowException(f"Batch failed:\n{batch_id}")
        if batch_state == Batch.State.CANCELLED:
            raise AirflowException(f"Batch was cancelled:\n{batch_id}")
        self.log.info("%s completed successfully.", self.task_id)
    def on_kill(self):
        if self.operation:
            self.operation.cancel()
class DataprocDeleteBatchOperator(GoogleCloudBaseOperator):