bug: Export tag over-applied to ~55% of Mach-O symbol strings #204

Problem statement

Classifying a Mach-O Rust binary tags an implausible share of strings as Export:

total rows: 47,820
tag counts: {'Export': 26,233, 'Import': 1,196, 'filepath': 977, 'b64': 11, 'Url': 8, 'fmt': 5}
rows with section == null: 26,199   # lines up almost 1:1 with the Export count

26,233 of 47,820 rows (55%) are tagged Export. A typical Rust binary exports almost nothing -- this strongly suggests local/private symbol-table entries are being classified as exports. This cuts against stringy's core thesis: "format-aware, meaningful strings, not raw strings" is undermined when more than half the output is mis-tagged symbol-table junk. The ~26k null-section rows are the same set (symbol-sourced strings carry no section, per GOTCHAS), so over-tagging is also what floods the output with section-less noise.

Proposed solution

1. Audit how Mach-O symbols are mapped to the Export tag (via goblin): confirm we are only tagging true exported/external symbols, not all symbol-table entries (locals, debug syms, stabs).
2. Add a regression fixture asserting a bounded, sane export count for a known binary.

Touches: container (Mach-O symbol handling), classification (Import/Export tagging).

Alternatives considered

• Suppress the volume in output only (e.g., via the default-limit issue): hides the symptom but leaves the mislabel; downstream --only-tags Export would still be wrong.

Area

Container parsing (ELF / PE / Mach-O)

Notes

Related to the default-output-limit and ranking-noise issues, but this one is about tag correctness, not volume. Evidence gathered from target/debug/stringy (Mach-O, arm64).