feat(skills): add agent-browser and electron skills with dev:cdp script

[DeJeune]

What this PR does

Before this PR:

• The agent-browser and electron skills were not available as public skills in the repository
• No convenient way to start the Electron dev server with Chrome DevTools Protocol (CDP) enabled for agent-driven UI verification
• Skills sync used symlinks which caused cross-platform compatibility issues on Windows

After this PR:

• Adds agent-browser skill (browser automation CLI for AI agents) and electron skill (Electron app automation via CDP) as public skills
• Adds pnpm dev:cdp script that starts the dev server with --remote-debugging-port=9222 using electron-vite's built-in REMOTE_DEBUGGING_PORT env var
• Skills are synced as file copies (not symlinks) between .agents/skills/ and .claude/skills/
• Adds agent-browser as a project dependency

Why we need it and why it was done in this way

AI agents working on Cherry Studio need the ability to visually verify their UI changes during development. The agent-browser + electron skills enable agents to connect to a running Electron instance via CDP, take snapshots, screenshots, and interact with UI elements.

The following tradeoffs were made:

• Used dotenv -v REMOTE_DEBUGGING_PORT=9222 for the dev:cdp script to leverage electron-vite's native CDP support rather than passing raw CLI args, ensuring cross-platform compatibility

The following alternatives were considered:

• cross-env for env var injection — rejected because dotenv -v is already a project dependency
• ELECTRON_EXTRA_LAUNCH_ARGS — not supported by electron-vite
• Replacing Playwright E2E with agent-browser — decided to keep them separate (Playwright for CI smoke tests, agent-browser for agent-driven dev verification)

Breaking changes

None

Special notes for your reviewer

• The electron-vite source code at node_modules/electron-vite/dist/chunks/lib-q6ns0vZr.js:225-226 confirms native support for REMOTE_DEBUGGING_PORT env var in dev mode
• Skills are copied (not symlinked) for Windows compatibility

Checklist

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

NONE