Emit GCSListObjectsOperator delimiter deprecation warning after rendering

[yuseok89]

related: #70296

The delimiter template field was inspected in init, so the deprecation warning fired on the unrendered Jinja value instead of the resolved one.
Move the check to execute() so it reflects the value the task actually runs with.

---

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

• Yes (please specify the tool below)
  • Opus 4.8

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[potiuk]

Thanks — clean and minimal. delimiter is a template field, so warning about it in __init__ checked the raw "{{ ... }}" string: a templated delimiter never triggered the deprecation notice, and a literal one warned on every Dag-processor parse rather than once per task run.

Two things I appreciated: you used the same _warn_on_deprecated_template_fields() helper name as #70449 and #70542, which makes the pattern greppable across the campaign rather than each operator inventing its own shape; and the test wraps the existing execute call in pytest.warns with context=mock.MagicMock() rather than None — several other PRs in this batch pass None and only get away with it because nothing reads the context before the warning.

Nothing further from me.

---

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

[github-actions]

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-3-test

You can attempt to backport this manually by running:

cherry_picker ee5f379 v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.