fix(core): never build fff index for workspace locations - #44563

What

FileSystemSearch chose its implementation from process-local facts only (platform, location.vcs, Protected.isHome), ignoring workspace placement. For a Location with workspaceID set, the fff layer built an in-process native index of location.directory on the server (packages/core/src/filesystem/search.ts:122-127) — an empty or foreign local directory — and served silently wrong search results while the real files live in the remote sandbox.

How

• layer in packages/core/src/filesystem/search.ts:184-196 now resolves Location.Service first and forces ripgrepLayer whenever location.workspaceID is set, before the platform/option/vcs checks. Ripgrep routes through the Location environment spawner (packages/core/src/ripgrep.ts:117-118), so it is the placement-correct seam.
• Added a focused test in packages/core/test/filesystem/search.test.ts that places a workspace-backed Location on a vcs+non-home directory (the combination that would otherwise pick fff on this platform), plants a server-local file, and asserts search results come from the ripgrep seam — not from an fff index of the server directory. The test fails without the guard.

Scope

This is the mechanical guard half of #44553 only. Until #44552 (executable identity) lands, remote ripgrep spawns can fail — this PR converts silently wrong results into an honest spawn failure, which is a strict improvement. Explicitly deferred:

• Placement-aware VCS detection (remains in fix(core): FileSystemSearch layer choice and fff indexing ignore workspace placement #44553).
• Making remote ripgrep spawns actually succeed (fix(core): ripgrep binary resolution ignores workspace placement #44552 owns executable identity).

Refs #44553

Testing

From packages/core:

bun run test test/filesystem/search.test.ts
bun typecheck
bunx prettier --check src/filesystem/search.ts test/filesystem/search.test.ts

All pass; the new test was verified to fail with the guard reverted.