Run the backport bot in CI

[tianyiy-tim]

Issues:

Addresses P425131803

Description of changes:

analyze, apply and publish still need someone to run them after a fix merges.

This pull request adds .github/workflows/backport-bot.yml, which runs all three automatically when a pull request labelled needs-backport merges. The decision to backport stays with the reviewers who apply the label, not with the tool.

It also adds the bot's own OIDC role to the CDK stack, chaining into the shared AwsLcGitHubActionsBedrockRole that #3376 renamed for exactly this.

Stacked on #3415. The base here is backport-stack/publish, a scaffolding branch holding the commits below it, so this diff is only the 7 files this change touches. I will retarget it to main as the stack lands. Please don't merge it into the scaffolding branch.

Call-outs:

• Two jobs, and the split is the point. analyze is the only job that reaches the model and it has contents: read. publish is the only job that can write and it never reaches the model. So repository content, which the model reads, is never handled by a job holding a token that could change the repository. The verdict moves between them as an artifact.

• The checkout is the merge commit, never the pull request head, so no untrusted code runs.

• The role is pinned by job_workflow_ref to this one workflow file. The bot can't borrow autofix's role and general CI can't borrow either. Renaming the file breaks the trust policy until the stack is redeployed.

• The pinning goes both ways, same as autofix: the general AwsLcGitHubActionsOidcRole now excludes this workflow file too, so the bot can't skip its own role and use the general one to reach the rest of CI.

• In CI the checkout already is aws/aws-lc, so the branches have nowhere else to go. --push-to-aws-lc says so out loud, is refused anywhere else, and push_branch only ever pushes a branch named backport-, so the escape has two independent limits.

• Two things this needs that merging it doesn't provide, and I can't do either: the CDK stack has to be deployed before the workflow can assume the new role, and a pull request opened with GITHUB_TOKEN starts no workflow, so the backport pull requests would arrive with no CI of their own. Getting them tested needs a token that isn't GITHUB_TOKEN.

• Uses Share Bedrock model settings between autofix and util/backport #3395 (merged) for .github/workflows/ai-config.json, which the workflow reads for the region.

Testing:

Unit tests - 6 new, 173 total:

python3 -m unittest testing.test_engine

They cover the --push-to-aws-lc escape, that the refusal still stands without it, and that only a backport- branch can be pushed.

CDK - synthesized the stack (no deploy) and read the rendered trust policies. The backport role is pinned to backport-bot.yml@*, the general role excludes both AI workflows, and the Bedrock role has one statement per OIDC role. Staging account path renders aws-lc-staging too.

Workflow - parsed it to confirm the two jobs hold the permissions above, analyze has no write access, publish has no id-token, the settings step runs before configure-aws-credentials, and the CDK pin matches this filename. I can't run the bot end to end until the role is deployed.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

[prasden]

Is it possible to create a shared role with autofix to use bedrock for both?

[prasden]

For this to work, we need to turn on Allow GitHub Actions to create and approve pull requests under Settings → Actions → General -> Workflow Permissions -> Allow GitHub Actions to create and approve pull requests. is this on?

This poses a security risk due to a GHA having perms to open a PR. However, since this is for backports, which are already established fixes, it might not be a big risk, but for autofix, had a discussion with @justsmth and he recommended against not turning this on as it could open a can of worms. If this was discussed beforehand then ignore.

[prasden]

Pin to a major version release so any vulnerabilities can be tracked