fix(labels): demangle the names a PE actually carries

[r0ny123]

Two reasons a PE reaches the report with mangled symbol names, both measured against real binaries.

Part of a linear stack: #249 → #250 → #254 → #255. This branch and #249 both touch RustSymbolProvider and do not merge cleanly on their own; resolving that conflict in this branch's favour would leave an import of a module #249 deletes, an ImportError on import smda that no test on either branch would catch. Stacked, the order resolves it.

RustSymbolProvider recovered nothing at all from a PE

Its COFF loop skipped a symbol when symbol.section is None. lief never populates that attribute for PE — which this repo already knows, because PeSymbolProvider carries a comment saying so and resolves through section_idx instead, fixed under #229. The identical sibling here was not swept at the time.

Measured on the bundled rust_pe_gnu_xored fixture (a mingw-linked Rust build):

COFF symbols                      4818
  with symbol.section set            0
  with a usable section_idx       4366

So the guard rejected every symbol, the provider contributed zero names, and PeSymbolProvider's raw spellings won by default. The report carried 2098 names spelled _RNv…. With the guard resolving through section_idx, the provider recovers 2098 names and none of them are mangled.

PeSymbolProvider never demangled anything

ElfSymbolProvider and MachoSymbolProvider both route recovered names through a demangler; the PE provider stored them verbatim, so a mingw-built C++ PE reported _ZN12FileExplorerC2Ev rather than a signature. It now applies the same demangle_itanium_symbol helper ElfSymbolProvider uses, which leaves non-Itanium names — including Rust ones, which belong to RustSymbolProvider — untouched.

There was no bundled PE carrying Itanium C++ symbols to show this on: the Rust fixture's names are all Rust-mangled and the other PEs have no symbol table. tests/cxx_pe_gnu_xored is a small C++ translation unit compiled for x86_64-w64-mingw32 by g++ 16.2.0, added so the path has a real binary behind it. Before and after, on that file:

                 mangled   readable
pre-fix                3          0
with the fix           0          3

giving demo::Widget::Widget(), demo::Widget::~Widget() and the full measure(std::__cxx11::basic_string<…> const&, double) const signature.

The gate in front of the revived loop

Bringing that COFF loop to life also made the test in front of it matter, and it was the wrong one. _is_rust_symbol checked the prefixes alone, but legacy Rust mangling shares _ZN with the C++ Itanium ABI, and RustSymbolProvider is consulted before the format providers. On a Rust binary that also carries C++ symbols it would therefore have claimed names like _ZN4test4funcEv and replaced the correct test::func() with the test::func its legacy demangler degrades that name to — shadowing the very demangling this PR adds. It now uses is_rust_language_evidence, which parses a name before claiming it. Recovery on the fixture is unchanged at 2098 names, so the stricter gate costs nothing here.

Scope of the sweep

The first bug's class is a PE symbol resolved through Symbol.section rather than section_idx. After this change no such site remains in the tree — the only surviving mention of .section in the label providers is the comment explaining why not to use it.

The second bug's class is a provider that stores a recovered name without routing it through the demangler for its format. ELF, Mach-O and now PE all demangle; the Go, Delphi and CIL providers handle name spaces that are not mangled in this sense.

Validation

Real binaries only, no synthetic symbol names:

binary	what it proves
rust_pe_gnu_xored (mingw Rust)	0 → 2098 Rust names recovered and demangled
cxx_pe_gnu_xored (mingw C++, new)	3 Itanium C++ names demangled, 0 left mangled
komplex_xored (Mach-O C++)	the Mach-O path already demangles 90 of 181 names — unchanged here

python -m pytest tests/ -q                  1190 passed, 1 skipped
make lint                                   clean
make typecheck                              exit 0, no new diagnostics

Still open after this

MSVC decoration (?name@@YAXXZ) is not demangled by this PR; #255, stacked on top, adds that.

[r0ny123]

Rebased onto a linear stack after a review pass found that this branch and #249 both touch RustSymbolProvider and do not merge cleanly. That mattered more than an ordinary conflict: #249 deletes rust_demangler/utils.py and its import, while this branch edits lines whose surrounding context is one of that helper's call sites, so resolving the conflict in this branch's favour leaves an import of a module that no longer exists — an ImportError on import smda that no test on either branch would have caught.

The order is now #249 → #250 → #254 → #255, and every pair of the open branches merges cleanly.

Two behaviour findings from the same pass are fixed here:

• The COFF loop this PR brings to life was guarded by a prefix-only Rust test. Legacy Rust mangling shares _ZN with the C++ Itanium ABI, and RustSymbolProvider is consulted before the format providers, so on a Rust binary that also carries C++ symbols it would have claimed names like _ZN4test4funcEv and replaced the correct test::func() with the test::func its legacy demangler degrades that name to. It now uses the shared evidence gate, which parses a name before claiming it. Recovery on the bundled fixture is unchanged at 2098 names.
• Several tests used _ZN3foo3barE as their Rust fixture, which has no 17h<hash> suffix and so is Itanium C++ rather than legacy Rust — the same distinction this PR's own description argues. They now use a name that really is Rust-legacy.