Fuzzy-search nested project folders in Add Project

[FabioPlunser]

Problem

Most people keep their repositories under one or two base folders (~/projects, ~/work/<org>/<repo>, ~/src, ghq trees). Add Project's local folder browser only lists one directory level at a time. To add a project three levels down you have to type or tab through the full path, and you have to remember where it lives.

Proposal

When you type a bare name (not a path) in Add Project's folder browser, fuzzy-match folder names across a set of base folders and list the nested matches.

• New per-environment setting, "Project search folders": a list of base paths (~/projects; ~/work). Empty falls back to the folder being browsed, so nothing changes for anyone who doesn't set it.
• Matching: subsequence match on the folder name, so hlw finds team/hello-world. Results show the path relative to the browsed folder.
• Server-side, bounded scan: the server walks each root breadth-first, skipping hidden folders, node_modules, vendor and symlinks. It stops after 20,000 folders per root, caches each scan for 30 seconds, and returns the best 100 matches. No persistent index or file watcher.
• Path input is unchanged: anything that looks like a path (~/, /, ./, C:\) browses exactly as it does today.
• Surfaces: web/desktop command palette and mobile Add Project. The setting is editable in Settings on web and mobile. Because it goes through the existing filesystem.browse RPC, it works for remote and tunnel connections too.
• While a search runs, the browser shows a spinner with what it's searching ("Searching folders for hlw in ~/projects…").

Questions for maintainers

1. Is fuzzy folder search in Add Project a direction you want?
2. Is a bounded in-memory scan (no on-disk index) acceptable, or would you prefer different limits or an opt-in?

I have a working implementation with server tests and am happy to adjust the scope.

Implementation and related work

Working implementation and captured before/after evidence: #32479. Companion new-project location setting: #32480.

Related PR #26376 improves substring and fuzzy matching within the current directory, but explicitly does not search subfolders. This proposal adds recursive search across multiple configured base folders. PR #18905 and discussion #14973 address the creation destination only.

Matching across file controls

PR #32479 now also applies fuzzy name matching to the shared folder pickers, direct directory browsing, the Files tree, and mobile ZIP filters. The Files tree preserves native fuzzy search results instead of removing them through substring-only filtering. Existing file, image, and mention pickers retain the native fuzzy index. Search scope and content-search options stay unchanged.

The PR includes regression tests and before/after captures showing rdm finding README.md, in addition to recursive project-folder search across several base folders.