Reconcile the project board on a schedule, under a GitHub App

[rocklambros]

Closes the automation half of #97, and picks up the follow-on #104 named for itself.

What happened

The board drifted for seven days without anyone noticing. Everything from #105 onward, 40 issues and pull requests, was never added. That included the external conformance reports (#109, #111, #113), the second independent implementation and its profile claim (#106), the whole accepted 0.1.3 set (#132 through #136), and every AGT reference implementation bug an outside contributor filed. A stale board looks exactly like a current one, which is why it held for a week.

The cause was narrower than it looked

Project 9 has six built-in workflows. Item added to project is enabled, which is why all 58 items carried a Status and not one was blank. What the project does not have is any auto-add for this repository. The only add workflow present is Auto-add sub-issues to project, which fires on sub-issues.

So the board sets Status correctly and never adds anything. A dry run of the reconciler put the split at 40 adds against 1 Status change.

The reconciler has since been run by hand. The board is at 98 items, every one with a Status.

What this adds

The real-time path is the project's own Auto-add to project workflow, which needs no credential and cannot be configured from here, since the GraphQL API exposes only deleteProjectV2Workflow and no way to create or enable one. That toggle is a manual step and this pull request does not do it. See below.

This workflow is the safety net under it. Nightly at 04:40 UTC, plus workflow_dispatch that defaults to printing the plan rather than applying it. The reconciler only adds an item or changes a Status field, never archives or removes one, which is the property that makes an unattended run acceptable at all.

On the credential, since #104 rejected exactly this

#104 turned down a workflow for a good reason, quoted from its own message:

Making it work means storing a personal access token with organization-wide project write as a repository secret, in a repository that opened to a hundred contributors this morning, where anyone who can land a workflow file can reach it.

and named the alternative:

A GitHub App is the right long-term answer and is separate work.

This is that work, and it narrows the objection twice rather than waving it off.

The grant is smaller. organization_projects: write plus read on this repository's issues and pull requests. A classic PAT with project scope carries write on every project the granting user can see, organization-wide, for as long as the token lives. The App reaches project boards and nothing else. What the job holds is a one-hour installation token, not the key that mints it.

The key is harder to spend. It lives in a board-automation environment rather than in repository secrets, with the deployment branch rule limited to the default branch. A workflow on a pull request branch, fork included, cannot read it even if it names the environment.

The residual risk, stated rather than assumed away. Landing a malicious workflow on the default branch still reaches the key. That is the path CODEOWNERS already guards: /.github/ carries a narrower owner list than the repository default, and the ruleset on main requires a code owner review. Two controls, not one.

Manual steps before this does anything

This workflow is inert until all three are done, and it will fail loudly rather than silently if they are not.

1. Create the GitHub App on the organization with organization_projects: write and read on issues and pull requests. Install it on this repository only.
2. Create the board-automation environment in repository settings. Add BOARD_APP_PRIVATE_KEY as a secret and BOARD_APP_ID as a variable. Set the deployment branch rule to the default branch.
3. Enable Auto-add to project on project 9, filtered to this repository. This is the half that actually prevents the drift in real time. The nightly job only catches what it misses.

Step 3 is worth doing even if 1 and 2 are declined, since it costs nothing and would have prevented 40 of the 41 drift events on its own.

Verification

• YAML parses, triggers and permissions read as intended.
• Both actions are SHA-pinned with a version comment, matching the convention in the other eleven workflows.
• No GitHub expression is interpolated into a run: block. Every value reaches the shell through env:, so the workflow-injection class is closed by construction rather than by review.
• Top-level permissions: {} with contents: read on the job.