fix(server): report incomplete usage scans - #5812

💭 Looking at how resolveClaudeTranscriptDir is being used, it acquires FileSystem and Path services via yield*, then re-provides those same services when calling the function — which is redundant since they're already in the environment. Looking at the conventions here — resolveClaudeTranscriptDir is exported at the module level and requires FileSystem/Path from the environment, with the test calling it via Effect.provideService. It's a bit redundant but follows the existing pattern already established elsewhere in the code, so it's not introducing a new violation. Though I'm wondering if exporting a helper purely for testability is the right call here. The test file itself follows conventions well: it uses namespace imports for effect modules, named imports from the vitest package, and imports the pure helper module correctly. The test passes a fake FileSystem through a Layer, which is an acceptable test seam. No new error types are being added, so that's fine too. Looking at the sageMerge.ts changes — those are pure functions in the web app, not Effect services, so they're straightforward. The catchCause pattern here is actually pre-existing code that's being moved, so I'm not flagging it as a violation even though the convention prefers catchTags for statically known failures. The real question is whether the explicit Effect.provideService calls for FileSystem and Path when invoking resolveClaudeTranscriptDir violate the convention about acquiring dependencies from the environment. The import convention issue in UsageService.ts is pre-existing and outside this PR's scope, so I'll skip it. Looking at the test file, it's using the correct namespace import pattern for the config module, and passing fake service instances like FileSystem is acceptable for testing. Checking for any Effect-related patterns like runPromise or ManagedRuntime — none present. The test uses satisfies FileSystem.FileSystem on a spread object, which is fine, and makeUsageLayer properly merges the FileSystem service as a test seam. The pure functions in usageMerge.ts and its test file don't raise any convention concerns. The 295-line test is justified since it covers genuine behavior changes around partial and failed statuses, not just mechanical refactoring. I should verify that UsageSourceStatus properly exports the new status values, but that's a behavior check rather than a convention violation. There's a redundant provideService call inside make for FileSystem, but since make already yields FileSystem at line 154, the requirement is already present in its signature — it's stylistically redundant but has precedent elsewhere, so I won't flag it as a concrete violation. The schema requires JSON output, but