fix(cli): guard six byte-indexed slice sites against multibyte/overrun panics

[yassine-ceo]

Summary

Fixes a family of byte-indexed string slices that can panic on multi-byte input, plus one out-of-bounds overrun. Regression tests were added before each fix (TDD, Red-Green) and each test fails on the pre-fix code.

Byte-boundary panics (sliced mid-character)

• truncate_iso_date (src/core/utils.rs) — &date[..10] sliced through a multi-byte character straddling byte 10. Closes truncate_iso_date byte-index slice panics on multi-byte UTF-8 input #3444. Now rounds the cut down to a char boundary: &date[..date.floor_char_boundary(10.min(date.len()))].
• parse_commit_output (src/cmds/git/git.rs) — &line[1..bracket_end] assumed byte 1 was a char boundary (panics on multibyte branch/author prefixes) and &line[1..0] on a line starting with ]. Closes rtk find panics on a non-ASCII directory path >50 bytes, and rtk git commit panics when the first output line does not start with [ #3415. Rewritten with strip_prefix('[') + rest.find(']').
• find dir display (src/cmds/system/find_cmd.rs) — &dir[dir.len() - 47..] sliced through a multi-byte character. Closes rtk find panics on a non-ASCII directory path >50 bytes, and rtk git commit panics when the first output line does not start with [ #3415. Extracted shorten_dir_display which rounds down with floor_char_boundary.
• short_month_day (src/analytics/gain.rs, print_ascii_graph) — &date[5..10] sliced through a multi-byte character. Same bug class as rtk find panics on a non-ASCII directory path >50 bytes, and rtk git commit panics when the first output line does not start with [ #3415 (spawned from panic: rtk gain --history crashes on non-ASCII (Cyrillic) command strings — UTF-8 char boundary #2954), not previously filed. Now rounds both ends to char boundaries.
• WeekStats::period (src/core/display_helpers.rs) — two &s[5..] slices with the same multi-byte hazard. Same bug class as rtk find panics on a non-ASCII directory path >50 bytes, and rtk git commit panics when the first output line does not start with [ #3415, not previously filed. Now rounds down to char boundaries.

Out-of-bounds overrun

• filter_migrate_status (src/cmds/js/prisma_cmd.rs) — unwrap_or(20) sliced past the end of a line when the migration token is line-final and shorter than 20 bytes. Closes prisma_cmd.rs migration-name slice panics with out-of-bounds index when token is short and line-final #3445. Now falls back to line.len() - pos, matching the existing migrate-dev path ~60 lines above.

Testing

• cargo test — 2549 passed; 16 failed are pre-existing core::stream tests that spawn Unix-only binaries (sh, true, false, echo, cat) and cannot run on Windows (they run fine in Linux CI and are untouched by this PR).
• cargo fmt --all --check — clean
• cargo clippy --all-targets — clean

All six new regression tests fail on the pre-fix code and pass after.

[CLAassistant]

All committers have signed the CLA.

[KuSh]

Three of the six sites in this PR are already fixed on develop: parse_commit_output was rewritten by commit f496f59 (2026-08-15), find's directory label truncates by chars since #3603 (merged 2026-08-26), and filter_migrate_status got its fallback in #3836 (merged 2026-09-11). What develop still lacks are the other three byte-indexed slices and their regression tests: truncate_iso_date's &date[..10] in src/core/utils.rs, the &date[5..10] in the gain ASCII graph in src/analytics/gain.rs, and the two &s[5..] slices in WeekStats::period in src/core/display_helpers.rs. Could you rebase onto current develop and narrow the PR to those three? It conflicts with develop, partly because src/cmds/git/git.rs has since been renamed, and that hunk can simply be dropped. Thanks for the careful audit.