feat(composer): show provider account usage in the composer - #6080

💭 The previous violations around split files have been resolved—the code now consolidates the Services and Layers into single files with inline interfaces and proper Effect patterns. I'm checking the new files for other potential issues, starting with import conventions and how they're using the Context and Service types. Looking at ProviderUsageLimits.ts, it's using Layer.effect with a scoped Effect, which depends on the Effect version—in v4 the Layer automatically provides scope, but I need to verify the repo's conventions. Meanwhile, ProviderUsageRefresher.ts imports ServerSettingsService as a named import rather than as a namespace, which might violate the service boundary convention that prefers importing the module as a whole and accessing its public shape. The ProviderUsageIngestionLive layer in the Layers directory is layer-only (using Layer.effectDiscard), which is acceptable even though it has a Live suffix typically reserved for services. Looking at how consumers import these—ws.ts imports ProviderUsageRefresher as a named import rather than a namespace import, which technically contradicts the convention about importing service modules as namespaces, though the existing codebase seems to do this widely with tags like ProviderRegistry. The ProviderUsageRefresher.make function acquires dependencies from the environment and provides them into the refresh effect, which exposes requirements in the layer type rather than hiding them in closures, so that's acceptable.… Now I'm reviewing the relocated service files and checking the head versions for any remaining violations. Looking at ProviderUsageRefresher.ts, the imports from the contracts package and the effect library appear to be in order. But I'm noticing some inconsistency in how service tags are imported across the codebase — some files use named imports like ServerSettingsService directly, while others use namespace imports like import * as ProviderUsageLimits. I need to check whether the named tag imports in this file align… The repo uses named tag imports as standard, which is fine. I'm noticing that HostProcessEnvironment gets yielded inside refreshClaude but isn't required at construction time—that suggests the dependency requirement might be leaking into the returned Effect, though refresh itself returns Effect.Effect<void> according to the interface. The runRefresh function provides several dependencies like HttpClient, FileSystem, Path, and ChildProcessSpawner, but HostProcessEnvironment is being yielded somewhere inside the refresh logic.… Both service modules are now aligned with the canonical pattern: single file, inline interface, using make and layer, with the service exported as Foo["Service"]. I'm looking at the remaining candidates, starting with ProviderUsageIngestion.ts in the Layers/ directory—it's currently a daemon-only layer named ProviderUsageIngestionLive exported via Layer.effectDiscard, but it doesn't follow the standard service export convention. The repo has many similar ...Live layers in … Checking the recent changes for any new violations — the type definitions in claudeUsageFetch.ts` look good with… I'm working through a conflict between the instruction to output "All clear" when there are no findings and the requirement to return JSON formatted results. The schema expects…