fix(find): never-worse guard, recovery hint, and dispatch on find's grammar

[aeppling]

Started as the benchmark negative on find --max 10; grew into making rtk find correct on every input shape, per review.

rtk find now parses arguments like find: options, then paths, then the expression. So find src lists src instead of matching a file named src. rtk walks only the subset it models (-name/-iname globs, -type f|d, -maxdepth, each once). Any other listing predicate (-path, -mtime, -not, -o, -type l, brackets, -mindepth, -L ...) runs the real find and its results go through the same compressed renderer. Actions (-exec, -delete, -print0, -ok ...) run through runner::run_passthrough: live output, stdin inherited, exit code kept.

rtk's own -m/-t are read only as trailing tokens and apply to both native and compressed runs; combined with an action they are refused rather than dropped. Legacy 'find ...' is rewritten to -name form and dispatched, never errors. The tee hint goes through runner::emit_guarded; default cap is CAP_INVENTORY; nonexistent path exits 1; no panic on long non-ASCII dir names.

Not changed, for the maintainer to decide: the native walker still skips hidden and gitignored entries and defaults to files (documented rtk behavior), and prints paths relative to the search root.

Verified: ~8k fuzzed invocations per iteration against GNU find and the pre-PR binary, 2713 tests, benchmark find cases all positive. The remaining CI red is the golangci-lint benchmark case, unrelated to this PR.

[pszymkowiak]

Tested the current head (8942e75) — the 3 previous fixes (tee-hint ordering, tracking dilution, stdin) all hold up. But the underlying dispatch logic (native vs RTK syntax vs unsupported passthrough) still has real bugs. All repro'd locally:

1. Crash on non-ASCII directory names (find_cmd.rs:388)

mkdir -p 'a😀aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
rtk find . -name "*.rs"

thread 'main' panicked at src/cmds/system/find_cmd.rs:388:34:
start byte index 4 is not a char boundary; it is inside '😀' (bytes 1..5 of string)

&dir[dir.len()-47..] slices at a fixed byte offset with no char-boundary check. Any dir name >50 bytes with a multi-byte char near that offset crashes the whole process instead of falling back to raw output.

2. Native flags outside the allowlist get silently misparsed as an RTK query

rtk find -mindepth 2

→ prints nothing, exit 0, no error. -mindepth isn't in UNSUPPORTED_FIND_FLAGS and isn't in the native-flag allowlist (-name/-type/-maxdepth/-iname), so it falls through to parse_rtk_find_args, which treats "-mindepth" as the glob pattern and "2" as the path. Silent wrong result, not an error.

3. Same root cause, but silently widens results instead of narrowing

find . -path "*/target/*" -name "*.rs"   # real find: only matches under target/
rtk find . -path "*/target/*" -name "*.rs"   # rtk: -path dropped, returns every *.rs file

-path/-user/-prune/-samefile etc. hit the catch-all unknown flag, ignored branch — the constraint silently disappears instead of narrowing or triggering passthrough.

4. -print0/-exec passthrough corrupts non-UTF8 bytes

printf 'binaire:\x00\x01\xff\xfe:fin\n' > bin.txt
rtk find . -name bin.txt -exec cat {} \;

Raw bytes ff fe come back as ef bf bd ef bf bd (double U+FFFD) — exec_capture_stdin decodes via from_utf8_lossy. Defeats exactly the byte-safety guarantee -print0 exists for.

5. Exit code depends on which path was taken

rtk find /does/not/exist -mtime -1   # passthrough → exit 1 (correct)
rtk find "*.rs" /does/not/exist      # normal path → exit 0 (wrong — main.rs hardcodes 0)

6. RTK flags + unsupported native flag together → forwarded verbatim, real find errors

rtk find "*.rs" . -m 5 -mtime +7

find: -m: unknown primary or operator

-m is RTK-only syntax; once -mtime triggers passthrough, the whole arg list (including -m 5) goes straight to the real find binary, which doesn't understand it.

Root cause across 1/2/3/6 feels like the same thing: UNSUPPORTED_FIND_FLAGS is a denylist of known-bad flags, so anything else defaults to "treat as RTK syntax" — the wrong default. Given how large real find's flag surface is, an allowlist of what RTK actually knows how to parse (falling through to passthrough for everything else) would close this whole class at once instead of adding flags to the denylist one at a time.

Also still open from earlier: -ok/-okdir missing from UNSUPPORTED_FIND_FLAGS (same silent-ignore behavior as #3 above, but for the interactive-confirm actions).

[pszymkowiak]

Re-tested at current head (988f2e3) — all 6 issues from the previous comment are fixed, verified locally:

1. Crash on non-ASCII dirs — directory labels now print in full, no more fixed-offset truncation. No panic.
2. -mindepth silently misparsed — now passthroughs to real find, which gives its own clear error instead of a silent empty result.
3. -path silently dropped — rtk find . -path "*/target/*" -name "*.rs" now returns exactly what real find returns.
4. -print0/-exec byte corruption — raw non-UTF8 bytes (ff fe) now come through untouched, no more lossy decode.
5. Inconsistent exit codes — both the passthrough and normal paths now exit 1 on a bad path (previously the normal path silently exited 0).
6. Mixed RTK+native flags — now surfaces real find's own error message instead of silently misbehaving. Not the smoothest UX, but honest and correct.

Also -ok/-okdir (flagged earlier, before this comment) now correctly triggers passthrough — the real confirmation prompt shows up.

Nice work tracking all of these down. LGTM on the correctness front — the remaining points from earlier (dead bail! branch in parse_find_args, group_by_dir computed twice, hand-rolled passthrough instead of run_passthrough) are just cleanup, not blockers.

[pszymkowiak]

All correctness issues found in review are fixed and re-verified locally (crash on non-ASCII dirs, -mindepth/-path silent misparsing, -print0/-exec byte corruption, inconsistent exit codes, -ok/-okdir passthrough). LGTM.