feat(pi-fff): search explicitly specified ignored paths via a scoped auxiliary index

## Summary

`fffind` and `ffgrep` currently cannot search a Git-ignored file or directory when it is explicitly supplied through the `path` parameter and remains inside the current workspace.

This is consistent with FFF's current indexing design: ignored paths are omitted during the initial scan, and `path` narrows the existing index rather than reading from disk. However, it is inconvenient for agent workflows that need to inspect a specifically named dependency, generated file, local configuration, or build artifact.

This is a `pi-fff`-specific feature proposal, narrower than a general `--no-ignore` mode.

## Example

Given:

```gitignore
node_modules/
```

and a real file at:

```text
project/node_modules/example-package/package.json
```

an explicit search such as:

```text
fffind(path="node_modules/example-package/", pattern="package.json")
ffgrep(path="node_modules/example-package/package.json", pattern="some-key")
```

currently returns no result when the main workspace index was used.

## Proposed behavior

When the caller explicitly supplies a concrete existing path:

- For a directory, create a scoped auxiliary finder rooted at that directory.
- For a file, create a scoped auxiliary finder rooted at its parent directory and constrain the query to that file.
- Search that scoped finder, allowing the explicitly requested path to be discovered even if it was ignored by the parent workspace scan.
- Keep the current ignore-aware behavior for searches without an explicit path.
- Keep the scoped finder short-lived or bounded by the existing auxiliary-finder cache; do not index all ignored files eagerly.

The implementation could generalize the existing `AuxFinderPool` path used for paths outside the workspace. The internal lookup should require the requested root to match exactly rather than reusing a broader finder that may already have excluded the target subtree.

No change to the default workspace index is proposed, and this should not require a core FFF `--no-ignore` mode.

## Acceptance criteria

- Normal `fffind` / `ffgrep` calls without `path` behave exactly as they do today.
- An explicitly specified ignored directory can be searched by both tools.
- An explicitly specified ignored file can be searched by both tools.
- Existing tracked paths continue to work.
- Broad globs and nonexistent paths retain their current behavior unless deliberately included in a later change.
- Tests cover Git-ignored directories, Git-ignored files, normal files, and both tools.

## Why this is useful

Agents often need to inspect files that are intentionally not part of the project index, including installed packages under `node_modules`, generated outputs, local configuration, and temporary tool results. Requiring a separate shell fallback makes the tool behavior inconsistent and loses FFF's normal path/search interface.

Related discussions:

- #108 — Does it support --no-ignore args?
- #406 — feat: option to search git ignored files
- #412 — Feature: Allow grep/glob outside search index
- #530 — API to control what is ignored and `--no-ignore` ability to index everything

This proposal is intentionally narrower: explicit path selection acts as the opt-in, while ordinary searches remain ignore-aware.

Start by tracing the existing AuxFinderPool path for paths outside the workspace and the path handling used by fffind and ffgrep. Add coverage for ignored directories, ignored files, normal files, both tools, and unchanged behavior for searches without an explicit path; done means explicit existing ignored paths are searchable without changing the default workspace index.

Written by the indexing model from the issue text.