chore(tools): Suppress noisy/sensitive paths from fs tool results

[JeanMertz]

The fs_list_files, fs_grep_files, and fs_read_file tools gain an options.suppress list of .ignore-style patterns for paths they may read but must never hand back to the model. .git/ and **/target/ are suppressed by default across all of them, so a search or listing no longer floods the model with build output or exposes repository internals it has no business seeing. Read access to those paths is unaffected: access.fs still governs what the tool process may touch, which is why fs_modify_file can keep running git status against a suppressed .git to check for uncommitted work.

A path skipped for suppression, or because the access policy denies read, is no longer silently dropped from listings and searches. The result now names what was skipped and why, and points at asking the user for the content instead of letting an empty result read as evidence the content does not exist. Explicitly naming a path (e.g. fs_read_file on an exact file) still reaches it even when a .ignore rule would otherwise prune it from an unscoped listing; only suppress and the access policy can withhold an explicitly named path.

fs_list_files and fs_grep_files also correctly handle a prefix naming a file directly, and a prefix naming a directory whose pruning rule lives below the workspace root (e.g. a nested .ignore), by walking that subtree as its own root instead of silently returning nothing.

Access-denial error messages from the fs tools now list only the paths that grant the specific denied capability, rather than every configured grant path, and point the model at asking the user for access rather than leaving the refusal as a dead end.