docs: record that ImageFileName is truncated by Windows, not by us

[h4x0r]

ps reports coreupdater.ex for a process whose executable is
coreupdater.exe, and that reads like a byte-loss bug. It is not — I filed it
as one and had to retract it, so the finding is written down where the next
reader will meet it rather than re-derive it.

_EPROCESS.ImageFileName is UCHAR[15] and the kernel NUL-terminates it,
reserving the final byte, so the field carries at most 14 CHARACTERS. Windows
truncates a longer executable name when populating it, before any tool reads it.

Confirmed in the artifact rather than reasoned from the struct definition. In
the Case-001 dump, for PID 3644:

0x02082cb38 coreupdater.ex\0 inside the _EPROCESS (PID as u64 within +/-0x400)
0x0195086ea coreupdater.exe\0 a different structure, not near that PID

So "read 15, stop at the first NUL" is correct and the short name is the
evidence.

Documented in three places, because each catches a different reader:

• docs/interpreting-process-names.md — for the examiner reading the output:
  what the short name means, that it is not a reliable identifier for names of
  15+ characters, where the full path actually lives, and why corroboration
  from a filesystem or registry artifact is needed before naming a file.
• process.rs at the read site, and psscan.rs on decode_image_name — for
  whoever next reads 15 and wonders whether it should be 16.
• The page is registered in mkdocs nav; an unlisted page is an undiscoverable
  one.

The decode is deliberately unchanged. Rewriting the field to the expected
filename would fabricate evidence: the tool would report a value that is not in
the dump. Fuller names belong as separate, attributed enrichment from
SeAuditProcessCreationInfo.ImageFileName or RTL_USER_PROCESS_PARAMETERS.

Refs #13.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com