fix(find): stop panicking on multi-byte UTF-8 directory names

[AZERDSQ131]

Closes #2851

rtk find's output formatter truncates long directory names for display with a raw byte-offset slice:

format!("...{}", &dir[dir.len() - 47..])

If dir.len() - 47 lands inside a multi-byte UTF-8 character (e.g. an accented letter like é), this panics with byte index is not a char boundary instead of printing a truncated path.

Repro (from the issue, reproduced in a unit test):

mkdir -p 'Les Plongées de Juliette/5-Pipeline/Versions-imprimables'
touch 'Les Plongées de Juliette/5-Pipeline/Versions-imprimables/LES-PLONGEES_Index-Tableau-de-Bord.pdf'
rtk find . -name '*Index-Tableau-de-Bord.pdf' -print

thread 'main' panicked at src/cmds/system/find_cmd.rs:326:34:
start byte index 10 is not a char boundary; it is inside 'é' (bytes 9..11 of string)

I confirmed byte 10 in that exact directory string is a UTF-8 continuation byte (0xA9), matching the panic message precisely.

Fix: extracted the truncation into a truncate_dir_display helper and walk forward from the target byte offset to the next valid char_boundary before slicing, instead of slicing blindly. The loop always terminates at dir.len() (always a boundary), so it can't infinite-loop or panic.

Adds three unit tests:

• truncate_dir_display_does_not_panic_on_multibyte_boundary — the exact directory name from the report
• truncate_dir_display_passes_through_short_paths
• truncate_dir_display_truncates_long_ascii_paths

Note on the "unknown flag" condition: the report mentions the panic only appeared alongside an unknown flag like -print. That didn't reproduce as a separate condition on my end — any directory name long enough to hit this truncation path panics regardless of flags, and this fix covers that unconditionally. If there's a second, flag-specific bug still lurking, happy to dig further with a maintainer pointer.

Ran the mandatory gate locally:

• cargo fmt --all — no changes needed
• cargo clippy --all-targets — clean
• cargo test --all — 2396 passed (+ 6/11/11/14/5/11 in the other suites), 0 failed

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}