Optionally restrict MSVC symbol demangling to import/export sources

[unclesp1d3r]

Context

Follow-up from #177 (MSVC symbol demangling).

Currently any ?-prefixed string from any StringSource is routed to try_msvc_demangle() in src/classification/symbols/mod.rs. The existing Rust (_R) and C++ Itanium (_Z) demangle paths behave the same way -- they do not restrict by source -- so the current behavior is consistent across all three demanglers.

As optional defense-in-depth, we could restrict MSVC demangling (and possibly the _Z/_R paths too, for consistency) to only the symbol-bearing sources (StringSource::ImportName / StringSource::ExportName), shrinking the untrusted-input surface that reaches the recursive parsers.

Why this was deferred, not done in #177

• Restricting only the MSVC path would diverge from the _Z/_R paths for no clear safety gain.
• It does not bound recursion depth on its own -- a long Import/Export name would still reach the parser. The MSVC_MAX_SYMBOL_LEN (4096) length cap is the higher-value mitigation and is already in place.
• Recorded as a rejected alternative in docs/adr/0001-msvc-demangler-length-cap.md (Alternative 3).

Scope

• Decide whether to gate demangling by StringSource for all three paths (consistency) or none.
• If pursued, gate in SymbolDemangler::demangle() / try_demangle_internal() and add tests asserting non-symbol sources are skipped.

This is optional hardening, not a known vulnerability -- the length cap already closes the stack-overflow DoS.