ci: stop auto-assign failing on bot and fork pull requests

[rashmiadvani]

Problem

The Auto Assign PR workflow fails on two whole classes of pull request. Because
it fires on every pull_request: [opened], the failure is not occasional — it is
guaranteed for any Dependabot PR and any fork-authored PR, so those PRs carry a
red ❌ that has nothing to do with the change under review.

This is the failure mode that trains reviewers to ignore red checks, which is
what makes it worth fixing rather than muting.

Failure 1 — bot authors cannot be assigned

Every Dependabot PR. Captured from an Auto Assign PR run log:

POST https://api.github.com/repos/embeddedos-org/eAI/issues/31/assignees
body:  {"assignees":["dependabot[bot]"]}
  ->  403  { message: 'Forbidden', status: '403' }

Failure 2 — fork PRs get a read-only token

Every PR opened from a fork. Distinct error, distinct cause:

POST .../issues/32/assignees
body:  {"assignees":["rashmiadvani"]}
  ->  403  RequestError [HttpError]: Resource not accessible by integration
##[error]Unhandled error: HttpError: Resource not accessible by integration

Per the GitHub Actions documentation: "The GITHUB_TOKEN has read-only permissions
in pull requests from forked repositories." The permissions: block cannot lift
that cap — it can only narrow what the token already has.

Root cause

#	Trigger	API response	Why
1	Author is a bot	403 Forbidden	Bot accounts are not assignable
2	PR head is a fork	403 Resource not accessible by integration	Fork pull_request runs get a read-only token
3	(latent)	—	addAssignees is the issues API; the workflow only granted pull-requests: write

Cause 3 never surfaced because 1 and 2 fail first, but it would break same-repo
PRs the moment they are the only case left.

The fix

• Guard the job so it runs only when assignment can actually succeed: the PR
  originates in this repository and the author is not a bot.
• Grant issues: write. addAssignees is part of the issues API and is not
  covered by pull-requests: write.

The assignment step itself is untouched.

Behaviour

PR source	Before	After
Same-repo, human author	assigned (or 403 if perms narrowed)	assigned ✅
Same-repo, Dependabot	❌ 403 Forbidden	skipped — no false failure
Fork, any author	❌ 403 not accessible	skipped — no false failure

Alternative considered and rejected: pull_request_target

The usual advice for cause 2 is to switch the trigger to pull_request_target,
which runs in the base-repo context with a writable token. I deliberately did
not do this, for two reasons:

1. It would not actually work. The docs state: "Only users with push access
   can add assignees to an issue. Assignees are silently ignored otherwise."
   Outside fork contributors do not have push access, so the assignment would be
   silently dropped. The check would turn green while doing nothing — strictly
   worse than skipping, because it hides the fact that nothing happened.
2. It carries real risk for no gain. GitHub warns that "running untrusted
   code on the pull_request_target trigger may lead to security vulnerabilities …
   including cache poisoning and granting unintended access to write privileges
   or secrets." Adding that trigger to buy a misleading green check is a bad
   trade.

Skipping the unsatisfiable cases is honest about what the workflow can do.

Verification

• ✅ PASS — actionlint clean on the modified workflow.
• ✅ PASS — Change is confined to .github/workflows/auto-assign.yml; 1 file,
  additions only.
• ✅ PASS — Both 403s are quoted from real run logs above, so the diagnosis is
  observed rather than theorised.
• ⬜ NOT RUN — The guard is not exercised by this PR. The workflow triggers
  on types: [opened] only, so updating this branch does not re-run it; there is
  no Auto Assign PR run against the fixed commit to point at. Its effect is
  observable on the first PR opened after merge.
• ⬜ NOT RUN — Confirmation that a same-repo human PR still gets assigned. I do
  not have push access here, so I cannot open a same-repo PR to test it. The
  assignment step is unchanged and issues: write only widens the existing grant.

I cannot claim this is verified end-to-end. What is established: both failure
modes are reproduced from logs, and the guard expression excludes exactly those two
cases. What is not: that the success path still assigns, and that the skip happens
in a live run. Reviewers with push access can confirm both quickly after merge.

Scope

The same defect is present in 13 org repositories; a matching PR is open for
each. eDB is excluded — it uses toshimaru/auto-author-assign, which already
handles this, and its CI is green.