fix(find): support multiple path arguments

[davidalecrim1]

Summary

• rtk find silently searched only the first path argument, dropping matches from any additional paths with no warning or error ([BUG] find with multiple path arguments silently searches only the first path #2839). This made it unsafe as a PreToolUse hook filter, since an agent could be told a file "does not exist" when it only existed under a dropped path.
• Both native (find path1 path2 -name ...) and RTK-shorthand (find <pattern> path1 path2 ...) syntaxes now collect all leading path arguments, and run() walks every given root through a single WalkBuilder.
• Display paths are stripped relative to the root when a single path is given (unchanged behavior); with multiple distinct roots, each result keeps its root prefix so files from different roots don't collide in the by-directory grouping.
• Identical path arguments are deduped before searching: a repeated root is walked once and reported once, rather than duplicating results, keeping output as compact and unambiguous as any other single-path search.

Test plan

• cargo fmt --all && cargo clippy --all-targets && cargo test
• Manual testing: rtk find pathA pathB -name "*.txt" inspected, confirmed matches from both paths; confirmed single-path output format unchanged; confirmed a repeated path argument (rtk find a a -name "*.txt") dedups to a single match
• Added unit tests for multi-path parsing and subprocess integration tests reproducing the original issue [BUG] find with multiple path arguments silently searches only the first path #2839 repro, plus a dedup regression test

Important: All PRs must target the develop branch (not master).
See CONTRIBUTING.md for details.

[KuSh]

Thanks for digging into the multi-path case. rtk find changed shape in #3603 (merged 2026-08-26): it dispatches on find's own grammar, and anything outside the single-path subset it walks itself, including find pathA pathB -name ..., is handed to real find with only its output compressed. On current develop rtk find folder1 folder2 -name '*.txt' returns matches from both roots, and #3854 (merged 2026-09-03) made a missing path report find's own error and exit 1, so the parsing and multi-root walk this PR extends are no longer there to extend. One thing develop does not have is an integration test pinning the multi-path result, and a small case in tests/guard_integration_test.rs would still be welcome. Worth noting that develop now prints a repeated path twice, as find does, rather than deduping it. If I have misread a case this PR covered, please comment or reopen.