codeSplitters checks: one panel for our runs and GitHub Actions, and a merge gate #465

Part of dogfooding: codeSplitters hosts codeSplitters (and RustyBuns), with GitHub as the backup. This issue ties together the build/CI runner (#463) and the desktop as the primary git store (#464).

What

One place to see whether a change is good, wherever it ran. A push to GitHub still triggers the existing pipeline (typecheck.yml, apps.yml), and codeSplitters can also build, test and gate on its own runs.

Scope

1. Triggers. A commit to main, an update to an open branch, and a branch pushed upstream each start check runs (codeSplitters CI: a build and test runner on the desktop and in a container #463). A setting per repo chooses where they run: here, github or both. RustyBuns starts with both, to compare the two.
2. GitHub results come back in. After a branch or commit goes up through the mirror, poll the GitHub check-runs / commit-status API for that sha with the existing token, and record each job as a runner: "github" check run. Actions results then show next to codeSplitters' own.
3. Our results go out. Optionally post codeSplitters' own check runs to GitHub as commit statuses (codesplitters/test), so a GitHub PR shows them too.
4. The UI and the merge gate. Show checks on the branch page, the phone page (codeSplitters phone page: show a branch's changed lines before Merge #426) and in the ⌘K palette. Merging waits for required checks, the same way it already waits for a person to read build-file changes. Add a checks MCP tool and OpenAPI operation, so agents can watch CI the way they run gh pr checks today.
5. Webhooks. Emit check_run events from src/hooks.ts in GitHub's shape.
6. Dogfood. Point RustyBuns' codeSplitters mirror at all of this and write down where it beats Actions and where it falls short.

Done when

• One codeSplitters branch shows both its own checks and the GitHub Actions jobs for the same sha.
• A required failing check blocks Merge.
• Tests cover triggers, the GitHub import (mocked API) and the gate.

Depends on #463 and #464 for real runs, but the triggers, the GitHub import and the gate can be built in parallel against the contract, with check runs inserted by hand.

The shared contract (all three issues build against this)

A check run is one record: { id, owner, repo, ref (branch or main), sha, name, runner: "desktop" | "container" | "github", status: queued | running | passed | failed | cancelled, started_at, finished_at, log (streamed), junit? }. It lives in D1 (a check_runs table) and comes in over GET /api/repos/:o/:r/checks?ref= and POST /api/repos/:o/:r/checks/:id/cancel. The runner (#463) writes them, the local store (#464) gives it a real checkout to run in, and the integration (#465) decides when to start them, shows them and gates merges on them. Whichever issue lands first adds the table; the others rebase onto it.