ci: arm auto-merge on Fern regeneration PRs

[antonwhop]

Why / Prompt

Fern opens an SDK regeneration PR in each of these repos and it then sits there until a human clicks merge. Three of the four things needed for those PRs to merge themselves are already configured: allow_auto_merge, a main ruleset with required status checks, and the Fern API app as a pull_request bypass actor so its PRs do not need the approval. The missing piece is the thing that arms each PR. This adds it.

Merging is not publishing — a version bump through publish-main.yml is still a separate deliberate act — so what lands on main unreviewed is generated code that the required checks have passed.

What changed?

• Adds .github/workflows/auto-merge.yml. On pull_request_target (opened, reopened, synchronize) it runs gh pr merge --auto --squash for a PR opened by fern-api[bot] (user id 115122769) from an in-repo fern-bot/* branch targeting the default branch. No actions are used, so there is nothing to pin; no PR code is checked out.
• Adds the workflow to .fernignore. .fernignore is read from the PR's base branch, so the entry only protects the file once this PR is merged — the file is unprotected against a regeneration that opens before this lands.

Choices, all four verified by running them against whopsdk-ruby#56:

• pull_request_target, not pull_request. pull_request_target runs the workflow file from the base branch, so a PR cannot edit the logic that arms it; pull_request runs the head copy and, for an in-repo branch, hands it a write-capable token. The job checks out nothing, so the usual pull_request_target hazard of executing untrusted code does not apply.
• Author, not just branch name. Any human with push access can create a fern-bot/* branch, so the load-bearing condition is user.id == 115122769, which cannot be renamed into. The branch prefix and an in-repo head-repo check are kept as secondary conditions.
• synchronize as well as opened. opened alone misses a PR Fern force-pushes to. Re-arming is safe: a second gh pr merge --auto on an already-armed PR exits 0.
• contents: write. Measured, not copied: with contents: read and pull-requests: write, enablePullRequestAutoMerge fails with Resource not accessible by integration.

This does not fully work yet, and the reason is not fixable from a workflow

Run on whopsdk-ruby#56 with GITHUB_TOKEN, gh pr merge --auto --squash succeeds and GitHub records:

autoMergeRequest: { enabledBy: { login: "github-actions" } }

GitHub attributes the eventual merge to whoever enabled auto-merge, not to the PR author. github-actions is app id 15368; the Integration bypass actor configured in all seven rulesets is fern-api, app id 244756. So the armed PR will still be held for the one required approval.

I did not observe the blocked merge itself — every open Fern PR in all seven repos is currently conflicted, so none can reach the merge point, and merging one was out of scope. The attribution and the permission requirement are measured; the block that follows from them is read off the ruleset configuration.

Closing that gap means making the arming identity one the ruleset already trusts. The narrow version is a dedicated GitHub App used only for this, added as an Integration bypass actor. Deliberately not done here: no ruleset was changed and no bypass actor was added, and bypassing blanket github-actions is the wrong answer because it would let any workflow in the repo merge anything.

Java-specific: two required contexts cannot report today

The ruleset requires compile, test, build, and decide. Only compile and test exist on main, from Fern's ci.yml; build and decide come from publish-main.yml, still unmerged in #2. Until that lands, an armed Fern PR waits indefinitely on two contexts that never arrive.