MCP grep results appear partial vs native grep (need exhaustive mode for drop-in routing)

### Summary

When using `fff-mcp` grep as a backend for a `grep -R -n --fixed-strings` workflow, results can be ranked/partial rather than exhaustive vs native `grep` for the same target subdirectory.

### Environment

- fff.nvim repo: `main` (as of 2026-04-10)
- install path: `fff-mcp` via `install-fff-mcp.sh`
- macOS host

### Repro (real monorepo case, sanitized)

```bash
API_SRC=apps/api/src
WEB_SRC=apps/web/src

# run from repo root
/usr/bin/grep -R -n --fixed-strings TODO "$API_SRC" | wc -l
/usr/bin/grep -R -n --fixed-strings TODO "$WEB_SRC" | wc -l

# fff-backed path (wrapper -> fff-mcp grep)
NCR_ENABLE_FFF_GREP=1 grep -R -n --fixed-strings TODO "$API_SRC" | wc -l
NCR_ENABLE_FFF_GREP=1 grep -R -n --fixed-strings TODO "$WEB_SRC" | wc -l
```

Observed in one repo:

- API native: `14`
- API fff-backed: `6`
- Web native: `4`
- Web fff-backed: `2`

### Minimal synthetic repro (public-safe)

```bash
ROOT="$(mktemp -d)"
mkdir -p "$ROOT"/apps/api/src "$ROOT"/apps/web/src "$ROOT"/docs "$ROOT"/scripts
cd "$ROOT"
git init

# 14 TODOs in api target path
for i in $(seq 1 14); do echo "export const a$i = 'TODO api $i'" >> apps/api/src/api.ts; done
# 4 TODOs in web target path
for i in $(seq 1 4); do echo "export const w$i = 'TODO web $i'" >> apps/web/src/web.ts; done
# noise outside target paths
for i in $(seq 1 80); do echo "TODO doc $i" >> docs/readme.md; done
for i in $(seq 1 80); do echo "echo TODO script $i" >> scripts/build.sh; done

git add . && git commit -m "seed"

/usr/bin/grep -R -n --fixed-strings TODO apps/api/src | wc -l
# expected: 14

# helper call used by wrapper
node ~/.local/share/ncr/bin/grep-fff-helper.mjs --path "$ROOT/apps/api/src" --query TODO --line-number 1 | wc -l
# observed here: 10 (lines 11-14 missing)
```

### Why this matters

For command-router use cases, `grep` compatibility requires shape + completeness parity for supported forms.

If FFF is intentionally ranked/preview-oriented, that is useful for AI workflows, but wrappers need an explicit exhaustive contract/mode before using it as a default native backend.

### Request

Would you consider adding one of these:

1. An explicit exhaustive grep mode for MCP/tool calls (native-like completeness), or
2. Tool metadata/options that clearly distinguish `ranked/preview` vs `exhaustive`, including paging semantics and termination guarantees.

Happy to test a proposed flag/contract and report back with parity checks.