feat(lists): GitHub-backed lists — repo picker, repo link, private tag, refresh, locked schema (#50)

[Adron]

Closes #50. Part of epic #49.

What changed

Repo picker on creation. The Lists FAB now opens a "New list" sheet with a Local / GitHub-backed
choice. The GitHub half picks a repository, optionally scoped by organisation, and sends
source: "github" + githubRepo + githubSource: "issues".

Which module owns the GitHub calls, and why. :feature:lists calls /api/github/… through its
own Retrofit interface and DTOs. :feature:integrations's IntegrationsApi/GitHubDto/
GitHubMapper are module-internal, and the repo convention is that no feature module depends on
another — a cross-module dependency would also have collided with the in-flight #40 work. The
duplication is ~100 lines of lenient DTOs, documented as deliberate in GithubDtos.kt.

Repository link + Private repo tag. GithubRepoLinkRow renders owner/repo issues under the
title, opening the repo's issues page. The tag copy is pinned by test and gets the distinction the
help text insists on: "This repository is private on GitHub… That is separate from who can see this
list", plus the sign-in / "not found" warning — and it never says "private list".
githubRepoPrivate: null (never synced) shows no tag — unknown is not rendered as public.

Refresh from GitHub appears in the top bar only for a GitHub-backed list, and the ViewModel also
refuses to spend the request on a local one (the endpoint 400s).

Row edits → issue operations. The row writes already used the correct { data } / no-If-Match
shape. What was missing was isReadOnly: SchemaMapper now parses it (plus the
propertyKey/propertyName/propertyType/validationRules spellings the synthetic GitHub schema
uses), so Issue #, Link, Created and Updated display but are never sent. The row form
names the operation ("Saving opens issue #42 in owner/repo") and delete reads "Close issue on
GitHub".

Schema editor locked to parent-only. Columns render read-only with an explanation; add / remove /
retype / save are refused in the ViewModel as well as hidden. A parent-list picker
(PUT /api/lists/{id} with parentId) is the one remaining edit.

GET /api/github/orgs drives the picker's organisation filter chips (?org=), and
next-issue-number drives the add-row hint. Both fit; neither was forced.

Unlinked case is not a broken picker: GithubLinkProblem distinguishes not linked from token
refused / missing Issues scope, each with its own explanation and a route to the connected-accounts
screen. An empty-but-successful repo list is explained separately as an org OAuth-approval problem.
#39 (OAuth linking) was not attempted — it remains blocked.

Live-API facts established while working

• POST /api/lists with source: "github" and no repo →
  400 {"error":"githubRepo is required for GitHub-backed lists (format: owner/repo)","code":"bad_request"},
  and the same for a repo with no slash. Client-side validation now matches the server exactly.
• GET /api/github/repos and /api/github/orgs return bare arrays;
  next-issue-number returns {"nextNumber": n}.
• githubSource is not validated before the GitHub call, so its accepted values could not be
  confirmed. "issues" is used because that is the only mapping documented — an informed
  assumption, not a verified one.
• On the test account GET /api/github/repos and /api/github/orgs both return 200 [], so an
  end-to-end create could not be completed here.

Verification

./gradlew clean :app:assembleDebug testDebugUnitTest → BUILD SUCCESSFUL, 1079 tests, 0
failures. New: GithubRepoLinkTest (copy), DefaultListsRepositoryGithubTest (create payload,
refresh route, synthetic schema, re-parent), DefaultGithubRepositoryTest (repos/orgs/
next-issue-number, unlinked/refused mapping), NewListViewModelTest, plus additions to
SchemaEditorViewModelTest and ListDetailViewModelTest. Compose tests compile, not executed (no
emulator) — which is why the tag's copy is also asserted by a JVM test that does run.

ListsDatabase v2 → v3, destructive migration already configured.

Risks / follow-ups

• The parent picker cannot clear a parent, because explicitNulls = false drops a null from
  the body. The module has the same pre-existing limitation for folderId. Clearing needs an
  explicit-JsonNull request shape.
• One behaviour change beyond the issue: ListsViewModel.createList was removed as dead code
  once NewListViewModel took over creation for both kinds. The FAB no longer creates an untitled
  "New list" instantly — it opens the sheet.