StackdriverRemoteLogIO: three bugs in AF3 supervisor context — empty labels, broken read filter, unguarded send crash

## Summary Three bugs found in `StackdriverRemoteLogIO` (introduced in #65198) when running against Airflow 3.2.2 with `apache-airflow-providers-google==22.1.0rc1` on CeleryExecutor. All three stem from the same root assumption: the implementation was written as if it runs in the **task subprocess**, but in AF3's supervisor model `REMOTE_TASK_LOG` runs in the **supervisor process** instead. Reproduced on APC 1.1.2 / GKE / CeleryExecutor / Airflow 3.2.2. --- ## Bug 1 — `proc()` ships empty labels to Cloud Logging **Location:** `StackdriverRemoteLogIO.processors` → the `proc` closure. **What happens:** Every log entry arrives in Cloud Logging with an empty `labels` dict. The `proc` function reads `record.task_instance` to populate `dag_id`, `task_id`, etc. but `record.task_instance` is never set in supervisor context — it is a task-subprocess concept. The attribute is `None` (or absent) on every record the supervisor emits. **Fix:** Parse labels from the structured log path that `relative_path_from_logger()` returns in supervisor context. AF3's log path template is: ``` dag_id=<x>/run_id=<x>/task_id=<x>/attempt=<N>.log ``` All four label fields (`dag_id`, `run_id`, `task_id`, `try_number`) can be extracted from this path with zero DB access and zero dependency on `record.task_instance`. --- ## Bug 2 — `read()` filters on `logical_date`, which supervisors cannot derive **Location:** `StackdriverRemoteLogIO.read()` → call to `prepare_log_filter`. **What happens:** `read()` constructs the Cloud Logging filter using `logical_date` (derived from `ti.execution_date`). But the supervisor has no DB connection to convert `run_id` → `logical_date`. The filter either crashes or returns no results. **Fix:** Filter on `run_id` instead. Both the write path (log path template, see Bug 1) and the read path (`ti.run_id`) expose `run_id` without any DB lookup. The filter becomes: ```python { "dag_id": ti.dag_id, "task_id": ti.task_id, "run_id": ti.run_id, "try_number": …