Pulls: read and reply to review threads #122

Pulls shows the parts of a pull request that only go one way: the checks rollup
(internal/project/prchecks.go), the commits it would land, the changed files,
and the two write actions that close the loop — Approve and Merge (v0.18.0 →
v0.21.0). What is missing is the conversation. A review that asked for a change
is invisible from lich, so reading it means going to the browser, which is the
thing the feature set out to stop.

Conductor's PR page landed on the same answer: git status, checks, deployments,
comments and commits in one timeline.

This is the deliberate next step past a limit already taken — reviewDecision is
rendered as the verdict alone (approved / changes requested), and the
per-reviewer breakdown was deferred on purpose.

Shape

• gh pr view --json reviews,comments plus gh api for the review threads —
  the same call path internal/project/pr.go already uses, under the same
  account resolution as every other gh call (vcs.account,
  internal/project/ghaccount.go).
• Threads anchored to their file and line render where that file's diff already
  renders; unanchored PR comments render as a plain list.
• Reply from lich, and resolve.

Open

• Do resolved threads collapse by default?
• Reply only, or also start a thread on a line? The latter overlaps with
  batched review comments — the same gesture then has two destinations (the
  session, or GitHub), and that fork should be decided once, not twice.
• Failure text goes through the gh message table (internal/project/gherror.go)
  — new failures here need their sentences, not raw gh stderr.
• Polling: the PR badge and checks already have a refresh cadence; threads
  should ride it rather than add one.