fix(core): FileSystemSearch layer choice and fff indexing ignore workspace placement

What

`FileSystemSearch` picks its implementation at Location construction from process-local facts (`packages/core/src/filesystem/search.ts:184-193`): platform, `location.vcs`, and `Protected.isHome` — with `location.vcs` itself detected via process-local Git during `Project.resolve`. The `fffLayer` then builds an in-process native index of `location.directory` on the server (`search.ts:116-127`).

For a workspace-backed Location this can boot fff against an empty or foreign server directory and serve wrong search results, while the correct data lives in the sandbox.

Fix direction

When `location.workspaceID` is set, force the ripgrep layer (already spawner-routed, lazily scanned, shared-attempt joined per #44526) and skip fff entirely. VCS detection for workspace Locations should be conservative or deferred until placement-aware detection exists. Depends on #44552 for the executable identity handed to the remote spawner.

Acceptance

• A workspace Location never constructs an fff index of the server filesystem.
• Lazy provisioning is preserved: search on a never-provisioned workspace triggers the shared provision attempt (existing behavior of the ripgrep layer).

Found while auditing boot-cycle process-vs-workspace resolution after #44526.

Start in packages/core/src/filesystem/search.ts, especially the FileSystemSearch choice at lines 184-193 and fffLayer construction at lines 116-127. Read the ripgrep layer behavior and the related work in #44526 and #44552 before checking workspace Locations. Done means workspace Locations never index the server filesystem and an unprovisioned workspace still triggers the existing shared provision attempt.