DF-5746 — leaked filename bytes across runs (baseline kernel)
On-disk LFN: "ABCDEFGHIJKLMNOP.k"  (18 chars, all ASCII)
Expected (no bug): the same characters (or '?' if conversion legitimately fails)
Observed (OOB read through unvalidated d_table pointers):

run R1 (run.1.log): 3f 3f 3f 3f 3f 3f 3f 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 02 01 4b 4d   (29 bytes)
run R2 (run.log):   3f 3f 3f 3f 3f 3f 3f 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 02 01 4b 4d       (same as R1)
run R3 (run.log):   4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 02 01 3f 3f 3f 3f 3f 3f 3f 02 01 4b 4d 3f          (28 bytes)
run R4 (run.log):   4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d 4b 4d  (36 bytes, all marker)

0x4b 0x4d ('K','M') = little-endian decode of marker strings "MK..." stored in the 16
neighbouring 4096-byte M_ICONVDATA allocations (marker charset pairs registered right
after the victim). 0x3f ('?') = slot whose OOB read hit zero bytes (error path).
0x02 0x01 = other live heap contents adjacent in the same zone.

Decode: each output byte pair (u,l) comes from code=d_table[c1][c2] read at
victim_alloc + 4096 + 512*rank(char); written to the dirent by
iconv_xlat16_conv (iconv_xlat16.c:243-244) via win2unixchr (msdosfs_conv.c:946).