fix(core): keep an import named like an ordinal from becoming one

[r0ny123]

A PE imports either by name or by ordinal — that is a bit in the thunk, not a property of the string. The report keeps only the string, so "#5" is ambiguous by the time synthesis reads it back: it is what the import parsers write for an ordinal nothing resolves, and it is also a legal PE import name.

PeSynthesizer._parseOrdinal read every #N as an ordinal. An import really named that way was therefore written as an ordinal thunk, and came back from the synthesized binary under a different name entirely.

This is the fourth and last hit from the sweep behind #260, which I had triaged there as needing a report-schema change. It does not — the information to settle it is already on both sides.

What settles it

An ordinal is a WORD. A number above 0xFFFF never came from an import table, so #99999 can only be a name. Writing it as an ordinal did not merely mislabel it, it truncated the value into a different import.

The parsers only write #N when no table resolves it. OrdinalHelper.resolveOrdinal("ws2_32.dll", 1) returns accept, so the parsers would never have written #1 for that DLL — a report holding it must mean a real import spelled that way. The synthesizer now applies the parsers' own test as its inverse.

What remains ambiguous is a real import named #N where that ordinal resolves nowhere for its DLL. That one still synthesizes as an ordinal — and re-analysing the result yields #N again, so the report round-trips unchanged. The divergence is invisible in the report's own terms, which is the property worth having here.

One structural change

The hint table and the thunk writer each decided independently which entries were ordinals, and each derived the DLL key separately (dll_name in one, dll or "unknown.dll" in the other). Now that the decision depends on the DLL, disagreeing would mean a KeyError on the hint lookup rather than a wrong byte. Both ends key on the same value, so they cannot drift.

Validation

The new test fails on the pre-fix tree and passes after it. Two existing robustness tests stubbed _parseOrdinal with a one-argument lambda and are updated — worth noting as the reason a private-method signature is not as private as it looks.

check	result
full test suite	1182 passed, 1 skipped, 1480 subtests
lint and format check	clean
type check	exit 0, no new diagnostics
diff coverage against master	100% (12/12 changed lines)