`@` file search returns nothing when cwd is the home directory — fff init failure leaves an empty stub, no ripgrep fallback

Description

When the working directory is the user's home directory (or filesystem root), file search returns zero results for the entire session — the @ autocomplete shows no files/directories, and /api/fs/find returns [] for every query.

fff refuses to initialize there (log: failed to initialize fff: Can not run certain FFF features in a file system root or home directories). That's reasonable, but packages/core/src/filesystem/search.ts handles the failure by installing a permanently empty stub:

if (!result?.ok) {
  ...
  return Service.of({
    find: () => Effect.succeed([]),
    glob: () => Effect.succeed([]),
    grep: () => Effect.succeed([]),
  })
}

instead of falling back to ripgrepLayer. The layer is chosen by Flag.OPENCODE_DISABLE_FFF || !Fff.available(), and available()\) is true even when create()` will fail for this directory — so the failure is silent and unrecoverable without the env var.

OpenCode version

1.18.15

Steps to reproduce

1. cd ~ && opencode serve --hostname 127.0.0.1 --port 4096 &
2. curl 'http://127.0.0.1:4096/api/fs/find?query=projects&limit=20' → {"data":[]} (also empty for query= and type=directory)
3. Restart with OPENCODE_DISABLE_FFF=1 → the same query correctly returns matching files and directories.

Expected behavior

When Fff.create() fails, fall back to the ripgrep search layer (or select the layer based on whether the directory is indexable) instead of returning empty results forever.

Note on the ripgrep fallback

Once the fallback kicks in, empty queries still return [] because it uses fuzzysort 3.1.0, where go('', items) yields nothing (fff returns all entries for an empty query, so the two layers disagree). Worth normalizing too.

Operating System

Linux (WSL2)

Terminal

Windows Terminal / bash