fix(web): keep generated muted foreground dimmer than entered text - #9113

1. browse_code — apps/web/src/themePalette.ts

2. browse_code — apps/web/src/themePalette.test.ts

💭 Now I'm checking the readableThemeText signature and standardMutedThemeText.

3. git_tools — readableThemeText|standardMutedThemeText

💭 Let me check the full implementation of readableThemeText around lines 1003-1030.

4. browse_code — apps/web/src/themePalette.ts

💭 I'm checking whether making mutedForeground mix toward text like placeholder does actually keeps it dimmer than text on the muted background, since the test requires mutedForeground's contrast to stay below text's contrast — worried the softening amount might push it too far toward full background instead. I confirm the amount-1 case searches between foreground and background contrast, matching the placeholder logic exactly, so line length and formatting look consistent with the existing style (printWidth around 100), and foregroundOn is still referenced elsewhere so nothing's orphaned. This looks like a small, consistent fix aligned with the theme system's contrast-derivation conventions. Now I'm checking whether deriving mutedForeground from textRgb loses per-surface hue solving, but since the contrast floor stays at 4.6 and the test only checks that mutedForeground's contrast is at least 4.5 and less than text's contrast, this should still pass. I also want to verify no other role depends on mutedForeground for cross-surface contrast, and whether mutedForeground should instead use the same standardMutedThemeText helper that sidebarMutedForeground and textMuted rely on for consistency, versus the managed path's readableThemeText approach. There's an edge case worth tracing: if text's own contrast against muted ever fell below 4.6, readableThemeText would just fall back to text itself, making mutedForeground equal to text and breaking the "less than text contrast" assertion — but this seems unlikely given the typical lightness offset between muted and its surface. I want to also check if any snapshot or bridge test depends on the previously generated colors elsewhere.

5. git_tools — mutedForeground

💭 The change checks out and foregroundOn is still used elsewhere. The mutedForeground now mixes textRgb toward the muted background instead of using OKLCH lightness solving, which preserves text hue and stays consistent with the placeholder logic right below—no risk of it colliding with placeholder styling. I should verify whether themeRgbToThemeColor also produces canonical OKLCH output like the previous version did.

6. git_tools — function themeRgbToThemeColor

💭 I'm checking whether mutedForeground being dimmer while other foreground tokens stay full-strength is consistent — muted-foreground is supposed to be muted, so this aligns with the managed path. This looks fine, ready to conclude with "all clear." Since output needs to follow the JSON schema, I'll set the state to success with title "UI Consistency: All clear" and summary "All clear" rather than a bare string response.