REST /pulls/{n}/comments returns no thread-level isResolved bit, so when
a reviewer clicked Resolve on github.com (or invoked resolveReviewThread
via GraphQL), `crit pull` left local Comment.Resolved at false. The local
review file silently disagreed with the PR.

Fix: add a GraphQL fetch over reviewThreads { isResolved comments {
databaseId } } and join isResolved onto each imported comment by
databaseID. The bit is shared across the whole thread (root + replies),
so only the root's Resolved / ResolvedRound is updated; replies inherit
thread state implicitly via the parent. ResolvedRound is stamped from
cj.ReviewRound, mirroring the local `crit comment --resolve` semantics.

Conflict semantics (asymmetric, follows Body precedent):
  - remote resolved + local unresolved -> set Resolved=true
  - remote unresolved + local resolved -> KEEP local (no clobber)
  - both same -> no-op

The asymmetry matters because crit doesn't push resolved state back to
GitHub, and a local user may resolve a thread via crit / crit-web
independently. A symmetric merge would silently undo that.

The GraphQL fetch is best-effort: a failure prints a warning and
proceeds with the existing REST-only merge, so token-scope or transient
GraphQL outages don't block a comment pull.

The previously-skipped roundtrip scenario
TestRoundtrip_GitHubThreadResolvedOnWeb is unskipped and passes against
crit-md/crit-roundtrip-sandbox.

Closes #453