Run scan and curves against a real D2R install and record the results

[Darithos]

Do this before anything else. It gates #2 and #3, and it closes the biggest gap in the project.

Everything built so far has been verified against synthetic Granny files constructed byte by byte. None of it has been run against a real Diablo II: Resurrected install. Two commands close that.

What to run

d2rmv scan   "C:\path\to\extracted\d2r" > scan.txt
d2rmv curves "C:\path\to\extracted\d2r" > curves.txt

d2rmv reads loose files, not CASC, so point it at an extracted install — the folder Noesis is already pointed at, or one produced by D2RExtractor or CascView. --limit 200 gives a fast first look.

Paste both outputs into docs/NEXT-STEPS.md under a "Survey results" heading, with the date and game version.

What each outcome means

scan reports section compression per section. That one line decides #3:

Result	Consequence
None	#3 disappears entirely. Plausible — CASC already compresses the container.
Oodle1 / BitKnit1 / BitKnit2	#3 is real but bounded; public decompressors exist.
Oodle0	No public implementation exists anywhere. Escalate; this reshapes the schedule.

Also worth capturing from scan:

• If the magic prints raw hex rather than LE32 (documented), D2R uses a Granny signature variant that could not be verified from documentation. Record the 16 bytes in docs/GR2-FORMAT.md.
• If pointer size detects as 8, note it. The 8-byte member layout in GrannyTypeTree is the least tested part of the reader.
• Bone counts per model — .m3 and the SC2 editor get unhappy past a few hundred.

curves reports the encoding histogram and ends with what each missing decoder is worth. That names the work in #2. The degree distribution matters just as much: if degree 2 is common, these are quadratic B-splines needing evaluation, not just decoding.

If it throws

A failure on real files is as informative as a success — it is the case synthetic fixtures cannot reach. Capture the error verbatim rather than working around it.