fix(core): extend FFF home protection to descendant locations

[opencode-agent]

Summary

• determine persistent FFF eligibility from the nearest worktree root instead of the selected location directory
• disable persistent indexing when that worktree contains the user home directory
• keep nested repositories below home eligible and preserve the exact-home scan exclusions

Fixes #44266.

Tests

• bun test test/filesystem/search.test.ts
• bun typecheck
• bun x prettier --check src/filesystem/protected.ts src/filesystem/search.ts test/filesystem/search.test.ts

Requested by: @kitlangton (Kit via Slack)

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

Right fix for a real trap: a repo accidentally initialized at $HOME made every subdirectory pass the old !isHome(location.directory) check while persistent indexing silently swept the whole home tree. Keying eligibility off the worktree root with a proper containment test closes that, and keeping nested worktrees below home eligible preserves normal usage. I verified containsHome's path.relative idiom against the four cases — self (""), descendant, ancestor (".."-prefixed), and unrelated-on-another-drive (absolute result) — and it behaves correctly in all of them; the tests covering child/self/parent boundaries are well chosen.

Two refinements:

1. Lexical-only comparison. path.relative does no filesystem resolution, so aliasing defeats it: macOS /tmp vs /private/tmp, /home/user vs an autofs/symlinked spelling, or Windows casing differences (C:\Users vs c:\users) would all slip past containment. Since both inputs ultimately come from real directories, normalizing through something like fs.realpathSync.native (with a try/fallback to the raw string) before comparing would make the guard hold under aliases too. Not blocking, but this is protection code — the failure mode is quiet and high-blast-radius.

2. Windows case-insensitivity: same category, cheaper fix — on win32, compare against a lowercased home (or lowercase both sides of relative) so C:\Users\Admin vs C:\users\admin isn't treated as unrelated.

Minor: isHome stays behind for its remaining callers — worth a follow-up glance that none of them are also making a "does this scope include home?" decision with equality-only semantics, since that's precisely the bug class fixed here.