fix(web): retain terminal PR badges after checkout switch - #4755

💭 Looking at the changed files, I notice ThreadStatusIndicators.tsx imports Atom from effect/unstable/reactivity as a named import, but the convention expects Effect library modules to be imported as namespaces from their subpaths. This looks like it might violate the pattern of using import * as Effect from "effect/Effect" style imports, so I should flag consolidated named imports from the effect package. I'm also noticing that setThreadChangeRequestSnapshot uses appAtomRegistry.modify, which is a module-level singleton registry imported into a component — that could be hiding dependencies in module globals, though it's at a React/UI boundary so I need to check how appAtomRegistry is structured. The test file imports from @effect/vitest rather than what might be the repo's standard test infrastructure, though that's more of a test setup concern than a convention violation. Since this is a behavior change, the tests themselves are justified. Let me dig into the actual repo to see what patterns are already established. The import pattern and singleton usage here align with the repo's conventions, so those aren't issues. I'm checking whether the test file's import from @effect/vitest is consistent with how it's used elsewhere in the codebase. The codebase relies on @effect/vitest for testing. The key pattern here is that instead of creating Effect services through Context.Service, the diff introduces an Atom paired with a module-level setter that writes directly to appAtomRegistry. There's an important asymmetry: the Sidebar reads from threadChangeRequestSnapshotsAtom via useAtomValue which goes through the RegistryContext, but updates bypass that and write straight to appAtomRegistry instead. I'm checking whether this violates Effect service conventions around dependency hiding and module globals. The repo already uses this pattern extensively in UI modules, and the guidelines say not to demand unrelated cleanup, so I need to focus on what's actually introduced here. Looking at the test file, I notice it's creating an AtomRegistry manually inside the test rather than using the proper Effect runtime setup. The imports look fine — named imports from packages are allowed, and the Effect imports follow the repo's conventions. The real question is whether resolveThreadPr is still being used elsewhere or if it's now dead code after the refactor. I'm noticing a conflict between the response requirements — the schema expects JSON output, but the check instructions say the final response should be exactly "All clear" when there are no findings. I think the resolution is to structure the JSON response to reflect no findings, with "All clear" mapping to the title or summary field rather than replacing the entire response format. Since there are no findings, this is a success state despite the check defaulting to failure. I'll set both the title and summary to "All clear" within the JSON schema, keeping the title under 60 characters as required. I've verified the rest of the diff — the Atom patterns are fine, no Effect service violations, and the Sidebar's use of the global registry function isn't an Effect service convention issue, so that's acceptable.