Revisit Code Suggestion's purpose/patterns in the IDE status bar

ℹ️ For second phase see: gitlab-org/editor-extensions&83

Context

In VS Code and JetBrains, the status bar is used to communicate the current state of Code Suggestions. The user can click on the icon to enable/disable the feature as well as hover to see a message about the current state. As more functionality is added (e.g. language blocklist) this toggle pattern becomes brittle and should be revisited.

Problems to solve

1. Does a user understand the scope and purpose of the status bar icon?
   • Is this the best way to communicate Code Suggestion's overall system status (enabled/disabled/error/loading)?
   • How does it differ from the gutter icon? Does the loading state of individual queries need to be reflected in both the gutter and status bar? (ie. configuration + license status vs current CS completion’s status.)
   • Do users understand the difference between Duo Chat and Code Suggestions since they use the same icon?
2. Are there better patterns for interacting with Code Suggestions settings that avoid overlapping states (e.g. disabled vs unsupported language) and allow more flexibility as we add functionality such as blocklisting languages?
   • Are there other ways to communicate status messages that don't rely on using the mouse?

example_statusbar_unsupported_language

Potential solutions to explore

1. Revisit the click/hover pattern. Are users frequently needing to enable/disable Code Suggestions? If not perhaps opening a context menu, quick pick, or command palette could be more useful.
2. Could error states be easier to troubleshoot if clicking opened an actionable notification instead?

Notification example

3. Should Code Suggestions have its own icon to differentiate from Duo Chat?
4. Could a unique icon/style better differentiate unsupported language and disabled states?

Target heuristics

Visibility of system status, consistency with platform standards, error handling