Validate workflow_run origin in chained_e2e before using the repo_name artifact

[adilburaksen]

chained_e2e.yml runs on workflow_run and consumes the repo_name artifact uploaded by trigger_e2e.yml (which runs on pull_request, forks included). download_repo_name doesn't currently verify that the run which produced the artifact came from this repository, so the downstream E2E jobs can take their checkout repository/ref from artifact contents that didn't necessarily originate from google-gemini/gemini-cli.

The fix is to validate the origin before consuming the artifact: gate download_repo_name on github.event.workflow_run.head_repository.full_name == github.repository, so a non-base-repo run falls back to the base repo/sha. If preserving E2E coverage for fork PRs matters, a maintainer-applied label gate is an alternative.

Implemented in #27753 (one file, ~16 lines).

Keeping the specifics light here since it's public; this came out of a Google OSS-VRP report and I'm happy to share full detail privately.

[adilburaksen]

Heads-up on the linked fix PR for this issue: #27753 was auto-closed by the stale-PR bot ("14 days without a help wanted designation"), even though both this issue and that PR are labeled priority/p1 + area/security and this issue is still open under status/manual-triage.

The change itself is small (size/S, +15/-1): it gates the download_repo_name step in chained_e2e.yml on github.event.workflow_run.head_repository.full_name == github.repository, so a fork can't have the privileged workflow_run job check out and execute its code with repo secrets.

My gh pr reopen was rejected, so I can't revive it from my side. Could a maintainer either reopen #27753 (and add help wanted / adjust the label so the stale-bot doesn't re-close a triaged P1 security fix), or let me know the preferred way to land it? Happy to rebase if it's gone stale. Thanks @sin325!