⚡ Bolt: Hoist search predicate string transformation in Launcher

[schmug]

💡 What: Added _searchable to the AppManifest, pre-populated during boot or statically. Updated Launcher to run query.toLowerCase() once outside the useMemo filter array.

🎯 Why: When mapping or filtering long lists on keydown events, calling .toLowerCase() on the query and concatenating a string per-element causes unnecessary object allocations and GC pressure on the main thread for every keystroke.

📊 Impact: Expected to reduce O(N) string allocations per keystroke in the app launcher (where N is total apps), leading to slightly reduced GC stutter.

🔬 Measurement: Verify tests pass via npm run test and linting works via npm run lint. Ensure behavior remains identical.

---

PR created automatically by Jules for task 7163933051281773504 started by @schmug

[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.

[schmug]

Closing without merge — the Launcher filters ~15 apps, and lowercasing that many short strings per keystroke is microseconds. There's no measured perf issue at this scale.

The proposed change also adds a leaky abstraction (a _searchable field on the public AppManifest type, plus an isLowercased flag on matches()) and creates a second place — alongside the mobile tile-count assertion — that has to stay in sync when apps are added. Per CLAUDE.md: "Don't add features, refactor, or introduce abstractions beyond what the task requires."

If the Launcher ever needs to handle 1000+ apps, the right move is a Map-based index, not annotating the manifest type.

[google-labs-jules]

Closing without merge — the Launcher filters ~15 apps, and lowercasing that many short strings per keystroke is microseconds. There's no measured perf issue at this scale.

The proposed change also adds a leaky abstraction (a _searchable field on the public AppManifest type, plus an isLowercased flag on matches()) and creates a second place — alongside the mobile tile-count assertion — that has to stay in sync when apps are added. Per CLAUDE.md: "Don't add features, refactor, or introduce abstractions beyond what the task requires."

If the Launcher ever needs to handle 1000+ apps, the right move is a Map-based index, not annotating the manifest type.

Understood. Acknowledging that this work is now obsolete and stopping work on this task. I will avoid premature optimizations for small lists in the future.