bound the trailing hex read in my_mb_wc_filename

my_mb_wc_filename decodes the 5-byte '@hhhh' escape but the length guard is off by one:

the s + 4 > e check only covers 4 bytes while the hex branch reads s[4]
a truncated @HHH whose buffer ends at s+4 over-reads one byte past e, reachable through well_formed_length/charpos on a my_charset_filename string with tight bounds
the existing s[3] ? guard only stops at a NUL terminator, not at the end pointer
bound the s[4] read against e; added a strings-t case that returns ILSEQ instead of over-reading (ASAN flags the read of size 1 past a 4-byte buffer before the fix).