Modes selector improvements

[brunobergher]

Description

Modes are one of RooCode's main differentiators – users who try different modes are much more likely to stick around.
But they can be hard to understand and can go unnoticed, especially as people are just getting started with the product.

This PR aims to improve that by:

• Highlighting the mode selector for new users until they click it for the first time
• Redesigning the mode selector to emphasize the list (no search, edit become settings)
• Bringing in short descriptions to help users choose the right mow (not yet reflected in the marketplace, mind you)

Test Procedure

The majority of the changes are in the UI, so testing is manual.

Type of Change

• 🐛 Bug Fix: Non-breaking change that fixes an issue.
• ✨ New Feature: Non-breaking change that adds functionality.
• 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
• ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
• 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
• 📚 Documentation: Updates to documentation files.
• ⚙️ Build/CI: Changes to the build process or CI configuration.
• 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Code Quality:
  • My code adheres to the project's style guidelines.
  • There are no new linting errors or warnings (npm run lint).
  • All debug code (e.g., console.log) has been removed.
• Testing:
  • New and/or updated tests have been added to cover my changes.
  • All tests pass locally (npm test).
  • The application builds successfully with my changes.
• Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Before

After

Documentation Updates

Does this PR necessitate updates to user-facing documentation?

• No documentation updates are required.
• Yes, documentation updates are required. (Please describe what needs to be updated or link to a PR in the docs repository).

---

Important

Enhances mode selector UI with a new component, state management for new user interactions, and telemetry tracking in TelemetryClient.ts.

• UI Enhancements:
  • Introduces ModeSelector component in ChatTextArea.tsx to replace SelectDropdown for mode selection.
  • Highlights mode selector for new users until first interaction.
  • Adds descriptions to modes in modes.ts for better user understanding.
• State Management:
  • Adds hasOpenedModeSelector to globalSettingsSchema in global-settings.ts and ExtensionState in ExtensionMessage.ts.
  • Updates ClineProvider.ts and webviewMessageHandler.ts to manage hasOpenedModeSelector state.
• Telemetry:
  • Updates TelemetryClient.ts to track mode selector interactions with setPeopleProperty() and getPeopleProperty() methods.

^{This description was created by for e45d2da. You can customize this summary. It will automatically update as commits are pushed.}

[daniel-lxs]

This looks really nice!

I left a couple of minor suggestions, also can you take a look at the conflicts so I can move this PR for review?

Thank you!

[brunobergher]

I don't love the complexity of this logic and the fact it's repeated elsewhere, but this was Roo's insistent suggestion on how to determine the changed setting and I couldn't figure out a different one which didn't lead to much more complex changes (eg one global event per setting change)

[daniel-lxs]

LGTM