#20688 webviews: composer surface lifts toward a theme token, not literal white (base red from #20561)

Fixes the base red that #20561 introduced: webviews/test/theme-colors.test.ts "a migrated stylesheet takes its colors from the theme" failed at the feat tip, because composerStates.css:28 mixed the light composer surface toward a literal white.

• New shared token --cmux-tone-light in pages/shared/desktop.css: the light end of the tonal scale. It is the one place that keeps white, marked theme-fixed, matching native ThemeTokens.opaqueOverlayFill, which mixes a light page toward .white.
• --acpmux-composer-surface now mixes toward var(--cmux-tone-light). Light themes paint the same pixels; the dark branch is unchanged.

Testing

• Red: bun test test/theme-colors.test.ts fails on feat tip (coordinator's base-red report at c3316947, composerStates.css:28 literal white).
• Green: the same command on this head passes, 7 pass, 0 fail.
• No visual change: the computed color is identical (#fff → #fff through a variable), so no recording.

Changelog

none

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes the theme-colors test failure from #20561 by lifting the light composer surface toward a shared theme token instead of a literal white.

• Adds --cmux-tone-light in desktop.css, the single theme-fixed place that keeps white, matching native ThemeTokens.opaqueOverlayFill.
• --acpmux-composer-surface now mixes toward that token; light themes paint identical pixels and the dark branch is unchanged.