du panic (`into_string().unwrap`) on a non-UTF-8 filename in the dereferencing traversal

Summary

When du walks a directory via its regular (non-safe) traversal — used whenever -L/--dereference is given, and always on non-Linux — it converts each entry name with entry.file_name().into_string().unwrap() to match it against --exclude patterns. A non-UTF-8 filename makes into_string() return Err, which is unwrapped and aborts the program (SIGABRT, exit 134). GNU du lists the directory normally and exits 0.

Steps to reproduce

$ mkdir -p duex/sub
$ python3 -c "import os; os.mkdir(b'duex/sub/\xff\xfedir')"   # non-UTF-8 dir name
$ du -L --exclude='zzz' duex
thread 'main' panicked at src/uu/du/src/du.rs:656:89:
called `Result::unwrap()` on an `Err` value: "\xFF\xFEdir"
$ echo $?
134

--exclude (any pattern) forces the name-matching path; -L selects the regular traversal on Linux. Plain du DIR on Linux uses the safe traversal and is unaffected.

Expected behavior

Match GNU: list the directory (the pattern simply doesn't match) and exit 0.

$ /usr/bin/du -L --exclude='zzz' duex
…
$ echo $?
0

Root cause

The exclude check unwraps the UTF-8 conversion of the entry name:

// src/uu/du/src/du.rs:656
… entry.file_name().into_string().unwrap() …

OsString::into_string() returns Err for any non-UTF-8 name. The sibling path check on the same line already uses to_string_lossy() for this_stat.path; the fix is to use to_string_lossy() here too (or match the pattern against the raw bytes) so a non-UTF-8 name is handled instead of aborting.

Found by our static analysis tooling.

Start at the exclude check in src/uu/du/src/du.rs:656 and inspect how the dereferencing traversal converts entry names before matching patterns. Reproduce with the non-UTF-8 directory and du -L --exclude='zzz' duex; done means the directory is listed without a panic and the command exits 0.