Honor impersonation_chain in deferred Cloud Build tasks

[SEPURI-SAI-KRISHNA]

CloudBuildCreateBuildTrigger accepts an impersonation_chain, stores it, and
serializes it — but built its hook without it:

def _get_async_hook(self) -> CloudBuildAsyncHook:
    return CloudBuildAsyncHook(gcp_conn_id=self.gcp_conn_id)

So the value travels correctly from CloudBuildCreateBuildOperator all the way into the
triggerer and is then discarded at the point of use. Once a CloudBuildCreateBuildOperator
task defers, its polling calls authenticate as the connection's service account rather than
the impersonated one.

Two ways this surfaces:

• where impersonation exists because the base account deliberately lacks permission, the
  deferred poll fails with a 403 that does not mention impersonation;
• where the base account has broader rights, the poll quietly succeeds under an identity
  the Dag author did not select.

The non-deferrable path is unaffected, so switching deferrable off appears to "fix" it.

Worth noting for reviewers: GoogleBaseHook.__init__ falls back to the connection's
impersonation_chain extra when the argument is absent, so deployments that configure
impersonation on the connection were never affected. The bug is limited to impersonation
configured on the operator — which is the documented parameter on every Google operator.

No newsfragment: this is a provider change, and provider changelogs are regenerated from
git log by the release manager.

---

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

• Yes — Claude Code (Opus 5)

Generated-by: Claude Code (Opus 5) following the guidelines

[SEPURI-SAI-KRISHNA]

Gentle ping on this one, it's been open since 12 August with no review yet.

It's a small change: the Cloud Build trigger builds its own hook on deferral and never receives the operator's impersonation_chain, so a deferred build polls as the default service account rather than the impersonated one. Two
files, +23/-1, CI green.

Happy to rebase or split it differently if that would help review.