fs_list_files needs pagination, git ls-files, blacklist options, or all of the above

The LLM, given a task under the architect persona, for some stupid reason pulled out the footgun of running fs_list_files with no arguments. There's a lot in target/ and this is ~2MB of data. Session exploded.

fs_list_files needs a pagination or window feature, returning ~50 files (probably directories first) and then explaining how to get later pages of results (and offering larger explicit ranges if the LLM is feeling brave). This is most important when called with no args, but probably suitable all the time.

One cheap stochastic hack might be to force the LLM to decide whether using actual fs or git ls-files, which is usually preferable anyway. git grep is usually preferable to grep, too. (It would also probably be sufficient to improve the user's project's description, to convince the LLM to not run this tool with no args, by talking about scary areas like target/ and saying more about how a cargo project is organized.)

It's not right to completely blacklist target/ (in any way that would cause surprising behavior in other personas), because certain logs that land there are on occasion useful. However it would be fine to blacklist target/ from the architect.

Start at the fs_list_files entry point and trace how its no-argument behavior is exposed to the architect persona. Resolve whether pagination, git ls-files selection, and architect-only target/ filtering are in scope; done means the chosen behavior limits large results, explains how to request more, and preserves useful target/ access where appropriate.