Two related fixes to the color picker UX:
1. Swatches now call applyCommand({type:'toggleMark', mark:'color:#x'})
directly instead of runCommand('color:#x'). runCommand emits the
'commit-set-format' sema event (which fires sound + visual feedback
on the editor surface). For discrete color picks the sema event is
noise — applyCommand bypasses the trigger and just mutates the doc.
2. Native <input type=color> uses `onchange` instead of `oninput`.
`oninput` fires continuously while the user drags the OS color
picker — each fire was queueing a separate command + sema event,
producing a horror cascade of sound / visual flashes on every
pixel of the slider drag. `onchange` only fires when the user
releases / commits the picker (closes the OS popup), so we get
exactly one command per intent.
Same pattern applied to both Foreground and Background pickers
+ the clear (×) buttons.
Sema events are still emitted by the rest of the drawer's action
chips (run via runCommand) because those are user-facing intent
actions (Bold, Italic, etc.) where the perceptual feedback aligns
with the user's notion of "I just did a thing". Color slider drags
are NOT in that category — they're continuous parameter tuning.
Verified: clicking the red swatch on selected "ActiveUI" produces
the expected red <span> in the document AND the trace shows no new
commit-set-format event (was previously firing on every swatch
click, drowning audio + animation).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>