Enable provider-based GCS remote logging resolution

[aaron-y-chen]

closes: #70266
related: #70265
related: #67056

Summary

Migrate the gs remote logging scheme to the provider dispatch introduced by #67056:

• add GCSRemoteLogIO.from_config(), preserving the legacy GCS config mapping and IO kwargs;
• register gs in the Google provider metadata generated from provider.yaml.

Core and the Task SDK can now resolve GCS logging through ProvidersManager. The existing legacy path remains as a compatibility fallback.

Validation

Tested against a real GCS bucket from Breeze using forwarded user ADC and:

remote_logging = True
remote_base_log_folder = gs://airflow-70266-<random>/airflow-70266
delete_local_logs = True

No remote_log_conn_id or google_key_path was set, so the handler used ADC.

• gs resolved to airflow.providers.google.cloud.log.gcs_task_handler.GCSRemoteLogIO;
• the task emitted AIRFLOW_70266_GCS_REMOTE_LOG_E2E_OK, and gcloud storage cat returned the same marker from attempt=1.log;
• the corresponding local log no longer existed after upload;
• the Airflow UI reported the gs://.../attempt=1.log source and displayed the marker.

Airflow UI reading the task log from GCS after local cleanup:

The uploaded attempt=1.log in the real GCS bucket:

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: [GPT 5.6 Sol] following the guidelines

[shahar1]

LGTM — a faithful port of the gs scheme onto the #67056 dispatch, matching the merged s3 (#69817) and cloudwatch (#69816) migrations line for line, with real-backend e2e evidence in the description. CI is green.

What I checked beyond the diff itself:

• Config parity with the legacy branch. from_config() reproduces airflow_local_settings.py L207–L224 exactly — same four keys, expanduser on base_log_folder, google_key_path → gcp_key_path, and the same | io_kwargs merge order. Existing gs:// configs resolve to an identical GCSRemoteLogIO.
• google_key_path unset (ADC) doesn't trip get_mandatory_value. [logging] google_key_path defaults to "" rather than None in config.yml, so the mandatory getter returns a falsy string instead of raising — same as the legacy path, and consistent with the ADC-only run in your description.
• Dropping the derived default conn id is fine. The legacy branch called _default_conn_name_from(..., "GCSHook"); provider dispatch deliberately doesn't (factory.py: "Provider dispatch does not produce a default conn id … providers that want a backend-specific default can read from their own hook inside from_config"). GCSRemoteLogIO.hook already reads [logging] remote_log_conn_id itself and falls back to ADC, and the supervisor's _remote_logging_conn prefetch only fires when that key is explicitly set — so no behaviour change, and it matches what #69817 shipped.
• Backward compatibility of the new provider.yaml key. provider_info.schema.json does not set additionalProperties: false in 2.11.1 (or on main), so the remote-logging block is ignored rather than rejected on older Airflow. The Compat 2.11.1 / 3.0.6 / 3.1.8 / 3.2.2 / 3.3.0 jobs confirm it.
• The test guards earn their keep. The hasattr(manager, "remote_logging_handler_by_scheme") skip and pytest.importorskip("airflow._shared.logging.factory") read as defensive at first glance, but they're exactly what lets this class run under the provider-compat jobs against Airflow versions predating #67056.

Smaller observations

• providers/google/src/airflow/providers/google/cloud/log/gcs_task_handler.py — this makes three verbatim copies of the ~18-line remote_task_handler_kwargs parse-and-split block (s3, cloudwatch, now gcs), with several backends still to migrate under #70265. Factoring it out is awkward while providers still support Airflow 2.11 — airflow._shared.logging.factory isn't importable there — so I'd leave this PR as-is and raise the dedup question on the umbrella issue instead. Purely a note, not a change request.

---

This review was drafted by an AI-assisted tool and
confirmed by an Apache Airflow maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Apache Airflow handles maintainer review:
contributing-docs/05_pull_requests.rst.

[aaron-y-chen]

Thanks shahar! 😁