Epic: GitHub integration and GitHub-backed lists #71

Summary

GitHub is a substantial product feature: lists that sync with GitHub Issues. Rows map to issues (title, body, labels, assignees, state) — adding a row creates an issue, editing updates it, deleting closes it. The app implements none of the nine /api/github/* endpoints and does not model the GitHub fields on a list.

Status correction

CLAUDE.md records that "every /api/github/* call returns 'GitHub account not linked'". That is no longer what happens:

GET /api/github/repos -> 200  []
GET /api/github/orgs  -> 200  []

(live, 2026-09-15). The endpoints answer the bearer token cleanly and return empty collections because the test account has no GitHub identity linked. So the service layer and UI are buildable now against an empty state; only the populated-data paths need an account with GitHub linked.

Endpoints

Plus POST /api/lists/{id}/refresh (manual refresh for GitHub-backed lists) and githubDefaultRepo on GET /api/user.

Verification note

Populated behaviour needs a test account with GitHub linked with the Issues scope. Build against the empty state, then verify the write paths before typing their responses strictly.

Repo conventions to follow

• Service: one partial class InterlinedApiClient file per domain in InterlinedList/Services/.
• Wire types in InterlinedList/Models/ matching real API JSON.
• ViewModel per view in InterlinedList/ViewModels/ (CommunityToolkit.Mvvm ObservableObject + [RelayCommand]).
• View is a self-contained UserControl in InterlinedList/Views/ that news up its own VM from AppServices.Session.
• Strata tokens only — no colors/fonts/radii outside Resources/Palette.xaml + Theme.*.xaml.
• Read-after-write for any mutating endpoint whose response envelope has not been live-verified.