fix: unify Editing Room accent color with brand palette

[Alfredoalv13]

Summary

• The Editing Room hardcoded a leftover blue (#2563EB) as its accent/selection color in ~180 places across 25 files, while the launch HUD and the app's own design tokens (--primary, --launch-accent) already use the brand burnt-orange (#B6410F). This swaps every chrome accent usage over to the primary token (or its literal hex in inline styles/rgba shadows), so the editor now matches the launch window's branding in both light and dark mode — both windows read the same .dark class from the shared ThemeContext, so this stays in sync automatically.
• Also updates the cursor click-effect default color and the default arrow/figure annotation color from the old blue to brand orange, per direction to use the established VybeClip branding rather than anything inherited from the original Recordly project.

Explicitly out of scope (left untouched)

• Generic background/annotation color-swatch pickers — legitimately include blue as one of many arbitrary content colors, not chrome.
• ItemGlass.module.css's per-clip-type timeline color palette. Two of its six clip-color families (glassGreen, glassCyan — the latter used for regular clips) also render as the old blue instead of an actual green/cyan, but deciding what they should look like is a separate design decision, not a mechanical token swap. Flagged as a follow-up task.

Test plan

• grep-verified zero remaining #2563EB (and its rgba(37,99,235,...)/blue-gradient-family equivalents) outside the two intentional exceptions noted above
• tsc --noEmit — clean
• vitest run — 834/834 tests passing
• Confirmed via code trace that --primary / --editor-* tokens are theme-aware and already used correctly elsewhere (button.tsx, skeleton.tsx)
• Visual check in the running app (light + dark) — screen-recording access to screenshot the Electron windows was declined in this session; recommend a quick manual look before merge

🤖 Generated with Claude Code

[Alfredoalv13]

Ran an internal bug-hunter review against this diff before merge.

Finding (fixed in 37041ff): three leftover Tailwind-blue text colors in UpdateToastWindow.tsx (#dbeafe ×2, rgba(191,219,254,0.9)) that the original regex pass missed — they weren't in the literal #2563EB substitution list, even though the sibling border/background/shadow declarations in the same style objects were already converted to brand orange. Result was light-blue text sitting on newly-orange badges/progress bar. Fixed to #d59d80 / rgba(213,157,128,0.9), matching the tan tint already used elsewhere in the same file for text-on-tint.

Everything else checked out clean: rgba math (37,99,235→182,65,15) consistent throughout, hex swaps (#2563EB→#B6410F) consistent, no malformed Tailwind arbitrary-value classes from the regex substitutions, and the two intentionally-untouched spots (SettingsPanel.tsx's generic color-swatch array, ItemGlass.module.css's clip-type palette) are exactly as scoped.

Re-verified after the fix: tsc --noEmit clean, vitest run 834/834 passing.