Check GCSToGCSOperator deprecation warnings after template rendering

[bramhanandlingala]

Fixes the google provider's GCSToGCSOperator entry from the #70296 exemption-list burn-down.

source_object, source_objects, and delimiter are template fields, but __init__ inspected their content (checking for a wildcard character, or truthiness of delimiter) to decide whether to emit a deprecation warning — so these checks ran on the un-rendered Jinja expression instead of the actual rendered value.

Moved all three deprecation-warning checks from __init__ into execute(), right before the fields are used. __init__ now only does plain assignments.

• Removed the three warnings.warn(...) blocks from __init__.
• Added the same three checks at the top of execute(), now reading self.source_object / self.source_objects / self.delimiter (rendered values) instead of the constructor arguments.
• Updated the two existing tests that asserted on these warnings (test_get_openlineage_facets_on_complete, test_execute_returns_list_of_destination_uris_multiple_files) to expect the warning on .execute() instead of construction.
• Added pytestmark = pytest.mark.filterwarnings("ignore::airflow.exceptions.AirflowProviderDeprecationWarning") at module level in the test file, since this repo's forbidden_warnings pytest config turns this warning into a hard error by default, and ~15 other existing tests exercise wildcard/delimiter inputs incidentally without testing the deprecation itself. This mirrors the existing pattern used in test_bigquery.py and test_kubernetes_engine.py for the same warning class.
• Removed the operator's entry from validate_operators_init_exemptions.txt.

Verified locally that scripts/ci/prek/validate_operators_init.py reports zero findings for this class after the change, and that the full existing test suite in test_gcs_to_gcs.py passes.

Related to #70296

---

Gen-AI disclosure: I used a generative AI tool to help identify the root
cause, write tests, and draft the PR description. I reviewed, tested, and
verified all changes locally before submitting.

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

• Yes - Claude

Generated-by: Claude following the guidelines

[potiuk]

Thanks for this — the change is correct and the diagnosis is right: these three deprecation warnings were firing against un-rendered template values in __init__.

Unfortunately it duplicates #70449, which makes the same change to the same file and was opened on 25 July, three days before this one. Airflow does allow parallel work on the same problem — "better PR wins" — but the convention is to check for an existing PR first and build on it rather than open a second one, precisely to avoid two people doing the same work.

Comparing the two honestly: #70449 extracts the warnings into a named _warn_on_deprecated_template_fields() helper rather than inlining them in execute, and it adds a test that builds a real DAG and asserts the warning fires on the rendered value — which is the actual behaviour being fixed. This PR adapts the existing tests to call execute but doesn't pin the rendered-value contract. On that basis I'm going with #70449, and I'm closing this one.

Genuinely though — the analysis here was sound. If you want to stay involved, a review on #70449 would be welcome, and there are still several operators listed in scripts/ci/prek/validate_operators_init_exemptions.txt waiting for exactly this treatment if you'd like to pick an unclaimed one.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting