[Suggestion]: share fff-mcp indexes without leaking worktree state

### Which fff frontend(s)?

- MCP server (fff-mcp)
- Core or Rust crate

### What problem are you trying to solve?

Agent hosts usually start one `fff-mcp` process per agent session. When several agents work in the same repository, each process builds its own index, content cache, watcher set, and scan threads.

Sharing one index for the whole repository would be incorrect because linked worktrees can have different branches and uncommitted files. Searches and refreshes must remain scoped to the worktree that initiated them.

### Proposed solution

Keep the stdio MCP process that each agent host expects, but make it a lightweight proxy:

- Run one shared Unix daemon per canonical Git common directory.
- Inside that daemon, keep a separate index session for each canonical worktree root and complete set of index-affecting options.
- Let agents in the same worktree reuse one index.
- Let agents in different worktrees share only the daemon process while retaining isolated files, Git state, watchers, refresh generations, and frecency data.
- Preserve local-process behavior as an opt-out and on non-Unix platforms.

I suggest landing this as opt-in first. Default-on behavior can remain a separate decision after broader platform testing.

I have a reviewed local implementation split into small dependent changes. On an Apple M5 Max, three runs against the public FFF tree plus 12,000 generated files showed:

- Eight same-worktree clients: RSS fell from 581.3 MiB to 207.2 MiB (64.4%).
- CPU time fell from 12.13 s to 1.58 s.
- Warm attachment fell from 69.7 ms to 12.1 ms median.
- All 160 mixed search requests per mode succeeded, with no cross-worktree isolation failures.

There are tradeoffs: one client uses 24.5% more RSS, mixed-query median increased from 2.53 ms to 5.42 ms, p95 increased from 6.24 ms to 7.91 ms, and some cold multi-worktree starts reached about 646 ms. These results support an opt-in rollout, not an unconditional default.

Before opening implementation PRs, I would appreciate feedback on:

1. Does one daemon per Git common directory, with sessions keyed by canonical worktree and index options, fit FFF's direction?
2. Should frecency remain worktree-local unless users explicitly configure a shared database?
3. Is an opt-in Unix daemon an acceptable first rollout?

Related work: #801 explores in-process sharing for `pi-fff`; #608 and #675 cover different worktree-discovery and multi-root concerns.

The issue names no implementation files or tests and is seeking design feedback rather than a defined coding task. Start by reviewing the proposed daemon/session boundaries and related issues #801, #608, and #675; done means reaching direction on the opt-in Unix rollout, worktree isolation, and frecency decisions.

Written by the indexing model from the issue text.