feat(orchestration-v2): add subagent observability data model (1/5) - #4768

💭 I'm reviewing the diff for Effect service convention violations, focusing on the mechanical changes to subagent projections, the new migration, and the SubagentObservability helper module. Let me check the imports in the modified files to see if there are any issues. Looking at the migration file and test file 044, they're using the correct pattern with namespace imports from Effect and SqlClient. The SubagentObservability module imports from contracts as named imports, which is fine. I need to examine the actual changed files like ProviderEventIngestor, Orchestrator, and ProjectionStore to verify their imports follow the conventions. Looking at the PR scope for subagent observability contracts, these are mostly mechanical changes—adding new fields, migrations, and event types that follow existing conventions. The imports are straightforward, using namespace imports from effect subpaths and named imports from the contracts package, so there don't seem to be any real violations in what's being changed. I'm checking the key files that could have issues—the Orchestrator and ProjectionStore changes—but these are existing services where the modifications are just adding event handling cases mechanically. I don't see any problematic patterns like Layer.succeed calling runtime APIs, ManagedRuntime.make, or .runPromise being introduced anywhere in the diff. The migration file correctly uses Effect.gen and yields SqlClient, which is the right pattern. Now I'm weighing the response format—the instructions say to respond with "All clear" when there are no findings, but the schema requires valid JSON output, and the system prompt is authoritative about that constraint. The PR looks good, so I'm generating the final JSON output now.