fix(shell): don't truncate config scan at a non-UTF-8 line - #3499

Problem

scan_file in src/shell/detection.rs iterated shell config files with reader.lines().map_while(Result::ok). map_while stops at the first Err, and BufRead::lines() yields Err(InvalidData) for any line that isn't valid UTF-8. So a single non-UTF-8 line — an accented comment saved as Latin-1, a stray binary paste — anywhere above the eval "$(wt config shell init …)" line caused the scan to stop before reaching it. Detection then reported shell integration as not installed for a config that is in fact installed, producing the exact incorrect-messaging outcome the module docstring's "Impact of False Negatives" section warns about (wt config show, the "installed but not active" hint).

Fix

Switch to filter_map(Result::ok) so a single unreadable line is skipped rather than truncating the whole scan, and move .enumerate() before the filter so a skipped line doesn't shift the 1-based line numbers of the lines below it (which feed unmatched_candidates / bypass_aliases hints).

Test

Adds test_scan_file_skips_non_utf8_line_before_integration: writes a .bashrc with a Latin-1 0xE9 byte on line 1 and a valid eval integration line on line 2, then asserts scan_file still matches the integration line and reports it at line 2. The test panics under the old map_while (the non-UTF-8 line stops iteration, matched_lines is empty, and scan_file returns None).

Low severity — shell configs are almost always UTF-8 — but a strictly-more-robust one-line change with no downside.