list_files ripgrep path still uses would_match_directory band-aid for the ignore-ancestor bug

Follow-up to #881, deliberately left out of that fix to keep its diff reviewable.

_list_files' local ripgrep path solves the same problem a third way: it writes the ignore patterns to the temp ignore file but drops any pattern that would_match_directory(pattern, directory) says would match the search root, then hands ripgrep the absolute root.

That works, but compared with the . + cwd=<root> approach now used by _grep:

1. It over-prunes in the other direction. Dropping **/tmp/** wholesale means a real tmp/ directory below a root that happens to sit under /tmp is no longer ignored either. The relative-to-root approach prunes it correctly.
2. Three mechanisms, one problem. _grep (cwd-relative), _list_files local (pattern filter), _list_entries_via_backend/_grep_via_backend (_relative_ignore_predicates). The next person to touch ignore semantics has to find all of them.

Converting the local path to the . + cwd shape would let would_match_directory (and its tests) go away entirely, leaving exactly two mechanisms -- one per HTTP... sorry, one per traversal style: subprocess and backend-walk.

Note also: code_puppy/tools/file_operations.py is ~1493 lines, well past the 600-line guideline. The natural split is grep / list / read-edit / subprocess-plumbing. Worth doing before more is bolted onto it, but not inside a bug fix.

Start in code_puppy/tools/file_operations.py, comparing _list_files' local ripgrep path with _grep's existing . + cwd approach. Trace would_match_directory and its tests, then update the local listing path so ignore patterns are evaluated relative to the search root. Done means the ignore-ancestor case is handled without over-pruning nested directories and the separate pattern-filter mechanism is removed.