perf(server): bound snapshot activity payload memory - #9000

💭 I'm reviewing the changed files against project conventions, checking things like import style and the use of SqlSchema/Effect.fn in ProjectionSnapshotQuery.ts, and noting the join hack in ActivityPayloadProjection.ts is explained by a comment rather than an unexplained lint suppression. The standalone shape interface pattern there predates this PR and isn't something this fix introduces or expands, so I'd hold off flagging it as a violation since it falls outside the change's actual scope.

1. browse_code — apps/server/src/orchestration/ActivityPayloadProjection.ts

2. browse_code — apps/server/src/orchestration/Layers/ProjectionSnapshotQuery.ts

💭 The imports look standard, and the pre-existing ProjectionSnapshotQueryShape service is already in place. I'm focusing on Effect service conventions rather than general correctness—checking imports, service definition, dependency acquisition, errors, and change discipline. One flag: the PR adds a large test to ProjectionSnapshotQuery.test, which conflicts with the guidance against adding large tests solely to prove a mechanical refactor. That said, since this changes backend behavior around client-mode projection, focused tests are actually warranted here. There are no added lint suppression directives in the diff, and dependency acquisition, error handling with toPersistenceSqlOrDecodeError, and the new SQL query patterns all follow existing conventions. I don't see a clear convention violation—everything from the span naming to the pure function imports to the type definitions inside the Effect.gen body looks consistent with the codebase's patterns. I should still check whether any lint-suppression comments were added anywhere in the diff and verify the test file's assertion style, plus confirm no unusual imports from "effect" were introduced. There are four files in the diff total, so I want to look at the Services file's doc comment and then examine the actual new code region in the Layers file more closely to make sure nothing else is off, like duplicated error handling or unusual use of catchIf.

3. browse_code — apps/server/src/orchestration/Layers/ProjectionSnapshotQuery.ts

4. git_tools — apps/server/src/orchestration/Services/ProjectionSnapshotQuery.ts b17cc3d..68f8bf0

💭 I don't see any Effect service convention violations here—the code follows existing patterns, with namespace-style imports for Effect modules and named imports for pure helper functions like projectActivityPayload, which is allowed since that module only exposes a pure helper. The behavior test change is fine—I traced through the fence-detection logic and confirmed the old and new code paths produce equivalent results, just structured differently (early return vs. accumulate-then-check). The Array.from(summary).join("") hack has an explanatory comment and isn't a lint suppression, so that's acceptable too. Retaining ProjectionSnapshotQueryShape and the duplicated raw/id-based SQL paths isn't a convention violation either, since this PR isn't restructuring the service definition—just adding a doc comment. With no actual findings here, I'll conclude the check as clear: state success, title indicating "All clear" for Effect Service Conventions, and a summary reading exactly "All clear".