Remove JetBrains SVG Runtime Colorization

Goal

Stop runtime SVG recoloring in the JetBrains plugin and rely on IntelliJ's standard light/dark icon asset resolution. Ensure every SVG asset used by the plugin has a light/dark pair.

Findings

• Runtime colorization exists only in frontend/src/main/kotlin/ai/kilocode/client/ui/SvgIconColorizer.kt.
• The only production caller is frontend/src/main/kotlin/ai/kilocode/client/session/scroll/ScrollButtonIcon.kt.
• ScrollButtonIcon colorizes two icons at runtime:
  • /icons/scroll-bottom.svg
  • /icons/scroll-question.svg
• Both already have dark variants:
  • scroll-bottom_dark.svg
  • scroll-question_dark.svg
• Other used frontend icons already have light/dark pairs:
  • send.svg / send_dark.svg
  • stop.svg / stop_dark.svg
  • shield.svg / shield_dark.svg
  • shield-filled.svg / shield-filled_dark.svg
  • compress.svg / compress_dark.svg
  • chevron-down.svg / chevron-down_dark.svg
  • arrow-up.svg / arrow-up_dark.svg
  • arrow-down-to-line.svg / arrow-down-to-line_dark.svg
  • kilo.svg / kilo_dark.svg
  • kilo-content.svg / kilo-content_dark.svg
  • plus.svg / plus_dark.svg exists, though no current direct source reference was found.
  • [email protected] / kilo@20x20_dark.svg exists, though no current direct source reference was found.
• src/main/resources/META-INF/pluginIcon.svg is present and has no pluginIcon_dark.svg. It is not referenced in source/XML, but JetBrains treats this filename conventionally as plugin metadata/marketplace icon, so it should be paired for completeness.
• The SVG assets use literal colors and no currentColor, <style>, CSS classes, or CSS variables were found in frontend/src/main/resources/icons/*.svg.

Implementation Plan

1. Replace ScrollButtonIcon runtime colorization with standard IconLoader.getIcon(...) loading.
   • Remove imports for colorizedSvgIcon, SessionUiStyle, UiStyle, JBUI, and Color from ScrollButtonIcon.kt.
   • Add IconLoader import.
   • Load bottom with IconLoader.getIcon("/icons/scroll-bottom.svg", ScrollButtonIcon::class.java).
   • Load prompt with IconLoader.getIcon("/icons/scroll-question.svg", ScrollButtonIcon::class.java).
   • Keep create(question: Boolean = false) unchanged so callers continue to receive the appropriate icon.
   • IntelliJ should automatically resolve _dark.svg variants when the look and feel is dark.
2. Delete frontend/src/main/kotlin/ai/kilocode/client/ui/SvgIconColorizer.kt after confirming no callers remain.
3. Remove now-unused scroll icon source palette constants from SessionUiStyle.ScrollIcon.
   • Delete the ScrollIcon object if no references remain.
   • This also removes stale comments about runtime colorization.
4. Add src/main/resources/META-INF/pluginIcon_dark.svg as the dark-mode pair for pluginIcon.svg.
   • Use the same artwork/colors as pluginIcon.svg unless there is a desired brand-specific dark variant; the current icon already has a black background and yellow mark, so an identical dark pair is acceptable and satisfies IntelliJ's expected pair convention.
5. Re-scan the JetBrains package after edits.
   • Confirm there are no colorizedSvgIcon or SvgIconColorizer references.
   • Confirm every used SVG path has a sibling _dark.svg where IntelliJ expects one.
   • Confirm no frontend SVG uses currentColor, <style>, CSS classes, or CSS variables.
6. Run the smallest relevant verification from packages/kilo-jetbrains/:
   • bun run typecheck or ./gradlew typecheck.

Files Expected To Change

• packages/kilo-jetbrains/frontend/src/main/kotlin/ai/kilocode/client/session/scroll/ScrollButtonIcon.kt
• packages/kilo-jetbrains/frontend/src/main/kotlin/ai/kilocode/client/session/ui/style/SessionUiStyle.kt
• Delete packages/kilo-jetbrains/frontend/src/main/kotlin/ai/kilocode/client/ui/SvgIconColorizer.kt
• Add packages/kilo-jetbrains/src/main/resources/META-INF/pluginIcon_dark.svg

Risks

• The scroll icons will no longer follow arbitrary runtime theme colors; they will use the static light/dark SVG asset colors. This matches the requested behavior.
• If a non-default theme expects palette overrides, static literal SVG colors still follow normal IntelliJ SVG handling better than custom byte-patching, but the exact custom-color behavior may differ from the old colorizer.