Summary

crit pull imports PR review comments from GitHub but does not surface the thread-level resolved state. When a reviewer marks a thread as resolved on github.com (or via the GraphQL resolveReviewThread mutation), the local review file's resolved flag on the imported comment remains false.

Repro

Reproduced by TestRoundtrip_GitHubThreadResolvedOnWeb in roundtrip_integration_test.go (build tag e2e_github). The scenario:

1. crit comment sample.go:19 'needs decision'
2. crit push (creates a thread on the PR)
3. Resolve that thread via GraphQL (resolveReviewThread).
4. crit pull
5. Inspect the local review file — comment.resolved is false even though the thread is resolved on GitHub.

Test fails with:

comment not marked resolved locally after thread resolution on web

Why this matters

• crit's local resolved flag is the source of truth for whether a comment still needs attention. Out-of-band resolves on github.com silently leak past it.
• A reviewer resolving a thread on github.com is a strong signal that crit should not re-list the comment as unresolved.

Likely fix area

crit pull (REST review-comments endpoint) does not expose thread resolution — the REST /pulls/{pr}/comments payload omits it. The fix likely needs a GraphQL query for pullRequest.reviewThreads { isResolved comments { databaseId } } joined onto the existing import path so each imported comment inherits its thread's isResolved.

Skipping in harness

Test will be marked t.Skip against this issue in the roundtrip harness so the suite stays green.