KubernetesExecutor retries can lose failed-attempt hostname and remote logs, leading to http://:8793 No host supplied

### Apache Airflow version 3.1.8 ### If "Other Airflow 3 version" selected, which one? Also reproduced on 3.1.1. ### What happened? We have multiple anonymized production incidents on Airflow 3.1.x with `KubernetesExecutor` where a task retries and the failed attempts are not retained correctly. The visible UI symptom is: ```text Could not read served logs: Invalid URL 'http://:8793/log/dag_id=.../run_id=.../task_id=.../attempt=3.log': No host supplied ``` But the more important observation is that the failed attempts already have broken metadata before log retrieval happens: - the surviving `task_instance` row for the final successful retry is normal - the corresponding `task_instance_history` rows for earlier failed attempts have `hostname=''` - those same failed history rows also have `start_date = NULL` - the remote log object for those failed attempts is missing from S3 - only the final successful attempt log object exists in remote storage This was first seen on Airflow 3.1.1 and still reproduces on 3.1.8, so it does not look fixed by later 3.1 patch releases. ### What you think should happen instead? When a task retries under `KubernetesExecutor`, each failed attempt should preserve normal historical metadata, including `hostname` and `start_date`, and its remote log object should remain accessible after later retries succeed. The UI should not end up constructing `http://:8793/...` for historical attempts. ### How to reproduce I do not yet have a minimal standalone reproducer, but the repeated field pattern is: 1. Run Airflow 3.1.x with `KubernetesExecutor` 2. Enable remote S3 logging 3. Run a DAG where a task fails, retries, and later succeeds 4. Inspect historical task attempts for that task/run Observed result in affected runs: - final `task_instance` row is normal and points to the last successful attempt - earlier `task_instance_history` rows for failed attempts have blank hostname and null start_date - remote log objects for those failed attempts do no…