⚡ Bolt: Cache colors map in StatusLine to reduce allocations

[himattm]

💡 What: Caches the output of colors.ColorMap() in the StatusLine struct using sync.Once and provides it to plugins via a new getColorsMap() method, instead of calling colors.ColorMap() repeatedly for each plugin execution.
🎯 Why: colors.ColorMap() creates a large map of ~80 string key-value pairs. In runPlugin, this map was being recreated on every execution. Since plugins run concurrently on every status line render, this caused unnecessary memory allocations, increasing GC pressure for hot paths.
📊 Impact: Reduces memory allocations by 1 map of ~80 strings per plugin per render. Given a status line with multiple sections and plugins rendering frequently, this is a measurable reduction in memory pressure and CPU spent on garbage collection without changing external behavior.
🔬 Measurement: Go benchmarks or heap profiling will show fewer map allocations per render. Tests pass perfectly.

---

PR created automatically by Jules for task 2747600555715842728 started by @himattm

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[gemini-code-assist]

Code Review

This pull request optimizes the status line by caching the colors map to reduce memory allocations and GC pressure during plugin execution. A potential data race was identified because the shared map is accessed concurrently across goroutines; it is recommended to explicitly treat the map as immutable to prevent application panics.

[gemini-code-assist]

Sharing a single map instance across concurrent plugin executions introduces a potential data race. In Go, maps are not thread-safe for concurrent read/write operations. Since renderLine executes plugins in parallel goroutines, if any native plugin modifies the Colors map, or if one plugin is being serialized to JSON (a read operation) while another modifies it (a write operation), the application will panic. While plugins are generally expected to treat this map as read-only, the previous implementation using colors.ColorMap() provided isolation by returning a fresh map for each execution. Please ensure that all consumers treat this map as immutable.

Suggested change

	colorsMap map[string]string // Cached static colors map to avoid allocations
	colorsMap map[string]string // Cached static colors map (read-only) to avoid allocations

[himattm]

Closing as superseded by direct commit 42f3149 on main, which consolidated the StatusLine color-map caching optimization without the generated .jules note.

[google-labs-jules]

Closing as superseded by direct commit 42f3149 on main, which consolidated the StatusLine color-map caching optimization without the generated .jules note.

Understood. Acknowledging that this work is now obsolete and stopping work on this task.