fix(web): make WSL settings searchable

[UtkarshUsername]

What Changed

Registered the WSL backend row in the Settings search catalog and added a stable anchor to the WSL row states.

Why

Searching for WSL previously returned no results because Settings search only matched catalog entries, while the WSL row was not registered. The entry is desktop-only because WSL management is unavailable in the browser client.

UI Changes

The WSL backend setting now appears when searching WSL in Settings and navigates to the WSL control in Connections.

Before:

After:

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

Low Risk
UI-only settings search and visibility wiring with unit tests; no auth, data, or backend behavior changes.

Overview
WSL backend is now discoverable from Settings search on Windows desktop, with search results staying aligned with whether the Connections row actually renders.

A shared isWslSettingsRowVisible predicate replaces inline visibility checks in Connections: the row stays visible on load errors, when WSL is available, or when the user still has WSL enabled or WSL-only; it stays hidden when WSL is unavailable and unused. All WSL SettingsRow variants use searchableSetting("wsl-backend") so search can scroll to a stable anchor.

The settings catalog gains a wsl-backend entry (desktopOnly + new windowsOnly), and searchSettings can take a filtered item list and drops Windows-only hits on non-Windows platforms. The sidebar search builds that list from live WSL state so wsl-backend does not appear when the row would be hidden, and clamps the active result index when the list shrinks.

^{Reviewed by Cursor Bugbot for commit 33b8cbd. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Make WSL settings searchable via searchableSetting("wsl-backend") and isWslSettingsRowVisible

• Adds the isWslSettingsRowVisible predicate in ConnectionsSettings.logic.ts to centralize when the WSL settings row should render, based on availability, enablement, wslOnly flag, or a load error
• Registers a new wsl-backend entry in SETTINGS_SEARCH_ITEMS with desktopOnly and windowsOnly flags, and extends searchSettings to filter windowsOnly items on non-Windows platforms
• Wires all WSL SettingsRow render sites in ConnectionsSettings.tsx to spread searchableSetting("wsl-backend") for a stable search anchor id and title
• Updates SettingsSidebarNav.tsx to query desktop WSL state and conditionally include the wsl-backend search item, with an effect to keep the keyboard navigation index in bounds
• Risk: windowsOnly filtering relies on navigator.platform; browsers that report an unexpected platform string could hide the WSL result on Windows

^{Macroscope summarized 33b8cbd.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 717d9b8f-4f6d-4a89-bd80-3fc91414a495

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Warning

Your free Security trial is over. An organization admin can activate Security or dismiss this notice.

---

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

One finding: the new wsl-backend search entry is only gated by desktopOnly, but the row it anchors to is Windows-only, so macOS/Linux desktop builds get a search result that lands on a missing anchor. Details inline.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding: the new wsl-backend search entry can still resolve to a row that never mounts on Windows desktop. Details inline.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Approved at 33b8cbd

Macroscope's review found this PR approvable — This is a focused settings-search fix that exposes an existing WSL control only where it is rendered, with stable navigation anchors and unit coverage. Its runtime impact is limited to settings UI filtering and a read-only desktop state lookup; it does not alter backend operations or product defaults.

^{You can add or adjust custom eligibility rules. Learn more.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0db864b. Configure here.}

[macroscopeapp]

One finding: the new search-visibility memo in SettingsSidebarNav.tsx reads desktopWsl.error but doesn't depend on it, so its WSL error branch never takes effect.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding: the sidebar's WSL visibility rule now diverges from renderWslRow when a failed revalidation keeps stale state, which re-opens the dead-anchor case this PR is closing.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

One finding: the WSL row's visibility rule is now duplicated between ConnectionsSettings.renderWslRow() and the sidebar's search filter, kept in sync only by a comment. The behavioral mirroring looks correct as written; the request is to make it a shared contract so it cannot drift again.

^{Posted via Macroscope — UI Consistency}

[SunkenInTime]

LGTM