### 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)

lifecycle_config = "lifecycle_config"
        if self.idle_delete_ttl:
            cluster_data[lifecycle_config]["idle_delete_ttl"] = {"seconds": self.idle_delete_ttl}
        if self.auto_delete_time:
            utc_auto_delete_time = timezone.convert_to_utc(self.auto_delete_time)
            cluster_data[lifecycle_config]["auto_delete_time"] = utc_auto_delete_time.strftime(
                "%Y-%m-%dT%H:%M:%S.%fZ"
            )
        elif self.auto_delete_ttl:
            cluster_data[lifecycle_config]["auto_delete_ttl"] = {"seconds": int(self.auto_delete_ttl)}
        return cluster_data
    def _build_cluster_data(self):