codeSplitters desktop: the primary git store, local out and GitHub in #464

Part of dogfooding: codeSplitters hosts codeSplitters (and RustyBuns), with GitHub as the backup. Sibling issues: the build/CI runner (#463) and the integration (#465).

What

Today a desktop mirror is GitHub-first: codeSplitters keeps a copy and syncs with upstream. This issue flips that around: local out, cloud in. The desktop's bare repos in ~/.codesplitters are the source of truth, and GitHub is a remote that gets pushed to as the backup and as the trigger for the existing Actions pipeline.

It works like Agent Office, which gives every worker its own local git worktree. codeSplitters becomes another git store that agents, runners and your own tools check out from.

Scope

1. Primary per mirror. A mirror setting primary: "here" | "upstream". With "here", sync pushes first, and a clash defaults to Keep mine but still asks. src/mirror.ts already does both directions and never force-pushes; this changes who leads, not the plumbing.
2. Real checkouts. A worktree per branch, or per agent run / check run, made with git worktree add off the bare repo, so agents and the runner (codeSplitters CI: a build and test runner on the desktop and in a container #463) work in a real directory. Remove them when the branch merges or the run ends.
3. A clonable remote for your tools. Document and test git clone http://localhost:…/owner/repo.git from the desktop's git http-backend, plus pushing back to it, so a terminal, an editor or Agent Office can use codeSplitters as their origin and GitHub as a second remote.
4. Outages both ways. If GitHub is down, nothing stops (that already works). If the desktop app is closed, GitHub still has everything up to the last push, and the Upstream panel says how far behind GitHub is.

Done when

• A repo set to primary: "here" takes commits locally and they reach GitHub on the next sync.
• A worktree can be made for a branch and cleaned up, with tests on a temp bare repo.
• REFERENCE.md documents the direction switch.

The real desktop app against real GitHub is covered by #407.

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.