fix(pi-fff): allow out-of-workspace path constraints

[edxeth]

Problem

pi-fff currently throws when find.path or grep.path resolves outside the workspace via path.relative.

Repro shape:

find({
  pattern: "init.lua",
  path: "/home/devkit/.config/nvim/**",
})

When the tool is called from a CWD of /tmp, path.relative('/tmp', '/home/devkit/.config/nvim/**') produces ../home/devkit/.config/nvim/**. The adapter throws:

Path constraint must be relative to the workspace: /home/devkit/.config/nvim/**

This breaks legitimate usage where the tool needs to search an unrelated directory from its current workspace.

Fix

Replace the throw with a passthrough. The ../ relative path continues through the normal glob-collapsing pipeline, so ** globs still collapse to directory-prefix constraints. FFF will return empty results, which is the correct silent-fail behavior for unindexed paths.

This keeps the change at the pi-fff adapter boundary. It does not change FFF core indexing, ranking, parser behavior, or matching semantics.

Tests

Updated the existing test from expecting a throw to expecting a silent passthrough:

• out-of-workspace path with /** → relative path with collapsed glob
• out-of-workspace nested path → relative path with collapsed glob

[dmtrKovalenko]

I'm not sure I undrestand your intention. File picker will not be able to find the files outside of working directory unless you will create a new one

[edxeth]

@dmtrKovalenko the throw was preventing any result at all. Without it, the path resolves to a relative ../ form and FFF returns empty silently instead of erroring.
The files still aren't found since they're outside the indexed directory, but at least the caller isn't blocked by an unrecoverable error and can fall back to other approaches.

[dmtrKovalenko]

wah do you mean to throw? I think in this case we should simply print out to LLM that this tool doesn't support file seach outside of base_path

[edxeth]

@dmtrKovalenko I was referring to this throw. I think you're right that returning empty is not ideal either but printing an unsupported-path message also feels like a fallback imho. Maybe the ideal fix is to route absolute paths to the correct cached finder, creating one for that base path if needed, so valid paths can be searched instead of just reported as unsupported?

In the meanwhile I close this PR.

[dmtrKovalenko]

I think it's a good finding and we should support it e.g. to spawn a new picker in the dedicated folder and search there but it indeed need to be reconsidered a bit more thoroughly