feat(protocol): add host browse endpoint for location picking

[heimoshuiyu]

Issue for this PR

Closes #46826
Fixes #46679

Type of change

• New feature

What does this PR do?

Every location-scoped fs endpoint runs through LocationMiddleware, so the
first read against any directory constructs the complete location runtime:
config discovery, plugins, watchers, and one MCP process set per server in that
directory's config chain. Directory navigation used those endpoints. The app
workspace picker preloads every child of the current root, and the TUI /cd
completion lists each parent directory while typing. Browsing a directory with
68 subdirectories spawned 68 runtimes and two local MCP servers each (~20 GB).

Navigation is not a location operation, so it gets its own surface:

• server.browse group with a single GET /api/browse/list?directory=<abs>
  served from the global FSUtil service: one stat plus one readdir, no
  location resolution, no runtime, no events. Sibling of the server-scoped
  groups; fs.list/fs.read/fs.find are unchanged for work inside an
  active location.
• The app workspace picker (tree, background preload, typed suggestions) and
  the TUI /cd completion navigate through browse.list.
• The sidebar file tree and @ mention search keep fs.list/fs.find: they
  run inside the open location and rely on filesystem.changed events and the
  per-location search index.
• Picker bare-word suggestions now match only the immediate children of the
  current directory (client-side fuzzysort). The previous recursive search was
  capped (result limit, visited-directory limit, ignore set), so whether a
  match surfaced depended on tree shape. The unused file-mode suggestion path
  is removed; no caller passes mode="file" today.

Generated client surfaces regenerated via bun run generate.

This follows #44272's read taxonomy rather than its mechanism: form and
permission queues are runtime-owned state, so #45994 can honestly return an
empty collection when no runtime exists. Directory contents are host-owned
state that exists regardless, so an empty fallback would be wrong and a
conditional host fallback would make fs.list's view depend on cache state.
#44272 anticipated this bucket: "Filesystem/VCS capability decomposition
... out of scope". This PR is that decomposition for the navigation case,
and it leaves fs.list free to become placement-aware (#44568) without
breaking pickers.

How did you verify your code works?

• packages/server/test/browse.test.ts: lists children (directories first),
  400 with a readable message for missing and non-directory paths.
• Dev server experiment: browse/list against 10 unloaded subdirectories
  returned 200 ten times with zero location services booted log lines and an
  unchanged MCP process count; a control fs/list against one more
  subdirectory still booted a runtime and spawned its MCP servers, so existing
  location behavior is retained.
• Full TUI test suite (1177 tests), app selection tests (23), and typecheck
  across protocol/server/client/tui/app.

Screenshots / recordings

No visual change. Picker suggestions are limited to the current directory's
children instead of recursive matches.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[heimoshuiyu]

closed in favor of #46970