refresh-amis still broken after #443: repo blocks Actions from creating PRs

[defangdevs]

Follow-up to #443

#443 changed refresh-amis.yml to commit the AMI-map bump to a branch, open
a PR, and merge it, because master's Require conversation resolution
ruleset (21491459, added 2026-08-25) now rejects a direct push with GH013.
Merged and verified via manual workflow_dispatch
(https://github.com/defangdevs/agent-box/actions/runs/33399687127) — it
still fails, one step later:

pull request create failed: GraphQL: GitHub Actions is not permitted to
create or approve pull requests (createPullRequest)

Confirmed the cause:

$ gh api repos/defangdevs/agent-box/actions/permissions/workflow
{"default_workflow_permissions":"read","can_approve_pull_request_reviews":false}

can_approve_pull_request_reviews is the repo's "Allow GitHub Actions to
create and approve pull requests" toggle, and it's off. So GITHUB_TOKEN
can't open a PR at all right now, regardless of what the PR would contain.

(Left the working tree as-is: the run's throwaway branch
chore/refresh-amis-33399687127 had a commit but no PR, so I deleted it —
nothing else to clean up.)

Why I didn't just flip the toggle

This is exactly the wall #176 already names: "it is the only reason an
agent cannot currently open a PR, review its own PR, comment on itself, and
cascade." can_approve_pull_request_reviews is repo-wide — flipping it
would let every GITHUB_TOKEN-authenticated workflow in this repo open
and merge PRs unattended, not just this one generated-content job. That's
a real security-boundary call, not a mechanical fix.

Options (does not have to be settled here — could fold into #176)

1. Flip can_approve_pull_request_reviews for this repo. Simplest, but
   repo-wide — every workflow gains create+self-approve, matching exactly
   the "ceiling" Self-maintaining repo: architecture, trust boundaries, and when a GitHub App becomes necessary (tracker) #176 warns about removing.
2. Ruleset bypass actor for github-actions[bot] on 21491459. Also
   repo-wide in effect: bypasses "changes must go through a PR" for any
   direct push from that actor, not scoped to this file or job.
3. Scoped credential for just this job — a fine-grained PAT or minimal
   GitHub App installation used only by the "Commit if changed" step to
   create+merge its own PR, everything else in the repo staying on
   GITHUB_TOKEN. This is the "cheapest intermediate step" Self-maintaining repo: architecture, trust boundaries, and when a GitHub App becomes necessary (tracker) #176 already
   recommends generalising from fix(ci): refresh-amis must dispatch the publisher, not rely on its push #173, and is the narrowest blast radius of
   the three — but needs a human to actually mint and store the credential.
4. Stop automating the merge. Have the job open the PR (once creation
   is allowed some other way) and stop there for a human to merge — keeps
   the review gate but reintroduces the original problem fix(ci): refresh-amis must dispatch the publisher, not rely on its push #173 fixed
   (nothing merges without someone noticing a stale PR).

My read: (3) is the right shape long-term and is already the direction
#176 points, but it's new-credential-provisioning work I can't self-serve,
so I'm not doing it unilaterally. Until one of these lands, the weekly AMI
refresh will keep failing at the "open PR" step every Monday.

Refs: #443, #176