ci: move linked issues across the backlog board from PR events

[bencap]

Summary

Moves issues across the MaveDB Backlog board as their PRs progress, so Status stops needing hand edits. mavedb-api, mavedb-ui and dcd_mapping2 each get an identical copy of the workflow and script (VariantEffect/mavedb-api#936, VariantEffect/mavedb-ui#749).

Closes VariantEffect/mavedb-api#937

• In review: opening, pushing to, editing or marking ready a PR into any branch but the default moves its linked issues to 👀 In review, or 🏗 In progress while it's a draft.
• Pending release: merging into a release branch (release-*, or mavedb-dev in dcd_mapping2) moves them to ⏳ Pending release, once no other open PR still links them.
• Release PR: a release branch's PR into the default branch gets a generated "Issues closed by this release" section at the end of its description. It lists each open issue linked from a PR merged into that branch since its last release, and is rewritten on every push. GitHub closes those issues on merge and the board's "Item closed" workflow sets ✅ Done. Hand-written notes above the section are left alone.
• Forward only: an issue never moves back, so a release PR linking an issue that's already Pending release leaves it there. That's why the board's built-in "Pull request linked to issue" workflow stays off.
• Closes lines: GitHub turns Closes #N into a link only on PRs into the default branch; on a PR into a release branch it's a plain mention. The script reads those lines from PR descriptions as well as the sidebar links.
• Sidebar links: linking an issue from a PR's Development sidebar fires no Actions event, so an hourly run catches those. Scheduled workflows only run from the default branch, so this starts once the change reaches mavedb-main.
• Not handled: issues that aren't on the board are skipped, because adding one fires the board's "Item added to project" workflow, which would race the status change. A PR closed without merging leaves its issues In review.
• PR template: a Closes line that feeds the automation, and a short checklist.

Adds two Actions: actions/create-github-app-token and actions/github-script.

Rollout

pull_request_target runs the workflow from the PR's base branch. Merged here, it covers feature PRs into mavedb-dev right away. The generated release list first appears on the mavedb-dev → mavedb-main PR after this one ships, since a release PR runs mavedb-main's copy. dcd_mapping2 has no patch/cycle split, so mavedb-dev is its only release branch.

Before merging: GitHub App

The default GITHUB_TOKEN can't write to org projects, so every run fails until this exists. One app covers all three repos.

1. Org Settings → Developer settings → GitHub Apps → New GitHub App. Untick Webhook "Active". Repository permissions: Issues read, Pull requests read & write, Contents read. Organization permissions: Projects read & write. Installable only on this account.
2. Note the App ID and generate a private key.
3. Install the app on mavedb-api, mavedb-ui and dcd_mapping2.
4. Org Settings → Secrets and variables → Actions: add the variable PROJECT_AUTOMATION_APP_ID and the secret PROJECT_AUTOMATION_PRIVATE_KEY (the whole .pem), both limited to those three repos.

Tests

Ran the script's read queries against live data. For release-2026.3.0 the generated list matches the 11 issues hand-listed in VariantEffect/mavedb-api#907 except that it adds VariantEffect/mavedb-api#865, which that list missed, and drops VariantEffect/mavedb-api#788, which no PR linked. For dcd_mapping2, the window for release #111 picks up exactly #106, #108 and #110 there. The board updates haven't run yet; the first check is a throwaway PR linking a test issue once the app exists.

[coveralls]

coverage: 0.0%. remained the same — feature/bencap/issue-status-automation into mavedb-dev