Conflicts, part 1: Resolve on a conflicted pull shows each conflict block as a card with ours, theirs, both or your own text #1966

Split from #1134 (the owner's ask: resolving a conflict by hand is a ten-second job). This part reads and chooses; it writes nothing to git.

Done looks like:

• [ ] A pure module src/git/conflicts.ts turns git merge-tree --write-tree output for a file into blocks (base text, the two sides named by their branch) and applies a list of choices (ours, theirs, both, or given text) to give the merged file.
• [ ] On a conflicted pull, "Resolve" (in src/web/pages/pull.ts) opens src/web/pages/conflicts.ts: one file at a time, each block a card with three taps and a text box, a running count (2 of 3 resolved) and the merged file beneath. Readers with write access only. Works at 360px; a hundred blocks scroll, they do not flood.
• [ ] Tests: a two-block conflict resolved by "both" gives the expected file; a text-box resolution is kept verbatim; the page shows the count.

Start from today's main, at or after 36daece8. The red 'the release record is newest first' on earlier tries was main's own fault (#1837, fixed in 39e98bc9), not the builder's. A new migration is a file src/core/migrations/<UTC yyyymmddHHMMSS>-<name>.ts (see 20261015230000-a-domain-drill.ts), never a number; do not hand-edit src/core/releases.json. Before pushing run bun x tsc --noEmit, the tests this touches, the schema-migrations and schema-additive tests if you add a migration, and test/check-list.test.ts; name every new test file in GATE in scripts/gate.ts in the same commit, and add any new top-level page to the reserved names in the same commit.