ci: grant PR Apply the statuses:write scope it needs

[Loup-Garou911XD]

What's wrong

Every PR Apply run that reaches the Report metadata fixpoint status step fails there with:

gh: Resource not accessible by integration (HTTP 403)
{"message":"Resource not accessible by integration",
 "documentation_url":".../commits/statuses#create-a-commit-status","status":"403"}

The step exits 1, which trips the if: failure() notifier into commenting "Automatic formatting/metadata could not be applied to this PR (patch touched a disallowed path, or a conflict occurred)" on PRs where nothing of the sort happened.

Most recent instance is #494, run 36406098267:

success  Validate patch (allowlisted paths only, no symlinks/binaries)
success  Apply fixups patch and commit
success  Apply Version Metadata using the TRUSTED script only
failure  Report metadata fixpoint status     <-- the only failure
success  On mechanical failure, notify the contributor

with FIXUPS_RESULT: success, VERMETA_RESULT: success, and both *_PUSHED empty. The branch was already at the fixpoint and the step was about to post state=success. The contributor was told the opposite.

Cause

statuses is its own permission scope. contents: write does not imply it, and once a permissions: block is declared every unlisted scope is none. The gh api --method POST repos/{repo}/statuses/{sha} call arrived in dcb50fd ("ci: fail loudly when PR Apply cannot apply fixups") and that commit never extended the block.

So this is not specific to #494. Every run since 2026-09-05 that actually reached the step has failed there: 36406098267, 36403742100, 34684974342. The one green run in that window (34678058897) took the proceed=0 skip path and never ran the step.

Consequence: metadata-fixpoint has never been set once since it was introduced. As a required check on main it currently blocks every PR.

The change

Adds statuses: write to the permissions: block, plus a comment recording why it is there so it does not get trimmed as redundant next to contents: write. Nothing else is touched, so the three hard rules in the file header are unaffected.

Verifying

This cannot be tested from the PR itself. workflow_run always runs the workflow file from the default branch, so PR Apply keeps using main's copy until this merges. First proof is the next PR Apply run afterwards.

Worth confirming Settings -> Actions -> General -> Workflow permissions is set to read and write as well. If it is read-only it caps the token regardless of what the block requests, and the 403 survives this fix.

Unrelated, but noticed on #494

That PR adds a single file named plugins/minigames/floating_impact, with no .py extension. autopep8, auto_apply_plugin_metadata.py, and the ALLOW regex in the validate step (plugins/(minigames|utilities|maps)/[^/]+\.py) all key off .py, so the pipeline cannot see it. That is why fixups.patch came back empty and the fixpoint check read the branch as clean. Even with this fix in place that PR would go green and merge without an entry in plugins/minigames.json. It needs renaming to floating_impact.py.

🤖 Generated with Claude Code

[github-actions]

Automatic formatting/metadata could not be applied to this PR (patch touched a disallowed path, or a conflict occurred). A maintainer will need to look at this manually.