feat(web): pull request surfaces — filters & qualifiers, all-server listing, update branch, reactions, in-place editing, smarter diffs - #6039

💭 Looking at the diff to understand what changed in the server files, particularly focusing on how the Effect service conventions are being applied. I'm examining GitHubReactionSubjectError in GitHubPullRequestCli.ts, which uses Schema.TaggedErrorClass with structured attributes like command and cwd, and has a detail getter that produces the error message — this seems to follow the pattern for defining service failures with tagged error classes and organized attributes. However, I'm noticing the error doesn't capture the repository, number, or subjectId at the wrapping site, which feels like missing context that… The error class follows the existing pattern consistently. Looking at the GitLab side, I see decoders like decodeOwnAwardIdJson rather than services. The setReaction implementation in the GitLab CLI uses Effect.gen to yield a GitLabMergeRequestReadError when a decode fails, specifying "setReaction" as the operation. I'm noticing that GitLabMergeRequestReadError is being… I'm checking that the error construction at the failure boundary matches the file's style, and verifying Azure has the unsupported helper already in place for cases like setReaction. Looking at the conventions now — Layer.mock in tests is fine as a test seam, and repositoryIdentityOf being exported from PullRequestService.ts works as a pure helper function.… Now I'm checking the service conventions in the server code, particularly the new and modified service files. The pull request checks module is a pure utility with no service layer, which is fine. In the PullRequestService, I see the setReaction method is using PullRequestOperationError with a detail field, which follows the existing pattern, though the convention guide has some notes about this.… Now I'm checking the details around the GitHub CLI's service-instance passing and verifying the PullRequestService.setReaction naming and gates look correct. The new pullRequestChecks.ts file and any decoders appear fine, so I'm moving on to examine the web app's pull request state management in full, which uses Atom.family and the app atom registry reference. Looking at the GitLab implementation, setReaction uses Effect.gen with proper error handling for decode failures. The GitHub side has GitHubReactionSubjectError that lacks repository/number/subjectId context, but checking the house style — sibling errors in the file like GitHubViewerLoginUnavailableError and GitHubDiffCursorError also carry minimal context, while GitHubDiffRevisionsUnavailableError includes a number. Since the convention permits both approaches and this mirrors the immediate neighbors, I'm not flagging it as an issue. Now checking the comment placement in the diff — the new helper functions pullRequestNodeId and reactionSubjectBelongsToPullRequest are inserted before the `gh` resolves a bare `owner/repo`... comment, which means the comment still precedes repositoryArgs as expected. That earlier finding was addressed, so no need to repeat it. The helpers reference graphqlRead which... Since graphqlRead and parseRepositorySelector are defined later in make as const arrow functions, calling them inside the helper bodies works fine due to lazy evaluation — not a convention issue. Looking at the other files like PullRequestReactions.tsx and PullRequestService.ts, they don't seem to violate any conventions either. Let me check GitHubPullRequestProvider.ts for any actual violations. The unsupported helper in the… Checking the GitHubPullRequestCli setReaction implementation against the helper error construction rule — it passes. The new code also follows the convention for acquiring Effect service dependencies from the environment, and the factory function takes pure values rather than service instances. The new interface additions to GitHubPullRequestCli are defined inline in Context.Service as expected. The data shapes like GitHubPullRequestDiffSlice and GitHubBaseComparison are properly separated from service shapes. The client state module in apps/web/src/state/pullRequests.ts uses Atom.make appropriately at the app boundary, and the PullRequestProviderApi interface in the server module follows the pre-existing port interface pattern rather than being a Context.Service. I'm verifying a few more spots to be thorough, particularly around the GitLabPullRequestCli.setReaction error handling where there's a potential mismatch between the operation name and the error class name. The rule targets redundant operation/reason/kind/phase fields that duplicate the error tag's distinction, but command: "gh" is a singleton field that's consistent with every other error class in the file—deviating from it would be inconsistent and arguably unnecessary cleanup. The new error class is properly added to the union and used correctly in GitHubPullRequestCli.ts, so… I'm checking the imports across the codebase—the pull request list logic file has the right Schema import, and in the GitHub CLI file I'm updating the import statement to include the named function resolvePullRequestAuthorFilter alongside the type imports from the contracts package, which aligns with the convention for whole package imports.…