feat(usage): add Grok reports to desktop and mobile - #5830

💭 I'm checking the in-scope files—usageProviders.ts, UsagePage.test.tsx, and UsageProviderChart.test.ts—and trying to reconcile a prior comment about a color value on line 29 that seems to actually reference the mobile app's color scheme rather than the web file itself. It looks like a hardcoded hex like #8b8b8b was previously used, and the current head has since replaced it with var(--contrast-muted-foreground). I want to verify whether that CSS token actually exists and is properly defined.

1. browse_code — apps/web/src/components/usage/usageProviders.ts

2. git_tools — contrast-muted-foreground

💭 With that resolved, I want to confirm GrokIcon exists in the Icons module, and since Codex already uses var(--contrast-foreground), using var() colors for chart/legend consumers should be fine too.

3. git_tools — GrokIcon

💭 I want to check how the mark color is rendered in usage components, like legend swatches and charts, and whether icons use currentColor and proper sizing. I'll look at how UsagePage.tsx and UsageProviderChart.tsx consume PROVIDER_PRESENTATION.

4. git_tools — PROVIDER_PRESENTATION|.mark|.color

💭 The web changes seem fine, but I'm second-guessing the color choice for Grok using muted-foreground versus Codex's plain foreground token—at high contrast settings that muted gray could blend too closely with the near-black/white foreground, making the two chart series hard to distinguish. I want to check line 1914 in index.css to verify.

5. browse_code — apps/web/src/index.css

💭 That resolves the earlier concern about the token being a proper semantic runtime-adjusted role. Though at maximum contrast, both foreground and muted-foreground converge toward the contrast target, making certain chart series look too similar—a mild issue that contrast-boost might partially address. I want to check the actual ranges for the contrast target and boost values to confirm.

6. git_tools — appearance-contrast-(target|boost|base)\s*:

💭 At maximum contrast, both series converge toward black or white, making the Codex and Grok lines visually indistinguishable since the chart conveys data by color alone. This feels like a genuine accessibility concern worth flagging, though I need to weigh whether it crosses the line into an optional aesthetic preference that shouldn't fail the check. Given the default-to-failure policy when no findings exist, I should actually trace where the contrast boost value gets applied at runtime to confirm this is real.

7. git_tools — appearance-contrast-boost

💭 I'm considering whether the two chart series colors could theoretically converge at extreme contrast/boost values like 200%, but that's an edge case worth questioning given the setting's actual allowed range. Since the previous review already flagged the hardcoded color issue and the author addressed it with a semantic token—the most conforming fix available—flagging this again seems unwarranted. I'll also verify there aren't other web files enumerating usage providers that were missed, like a color map or provider literal union elsewhere that should also include the grok entry.

8. git_tools — codex.*claude|claude.*codex

💭 No other web usage findings turn up, so nothing else needs flagging here. Since a JSON response format is required, I'll frame the output as a success state with a concise "All clear" summary rather than literal free text.