fix(filetype): emit each identity tag once, under the File group

[swackhamer]

oxidex -json emitted FileType and MIMEType twice on any file that reached a parser — once under File:, once ungrouped — and on 21 of the 194 files in ExifTool's own t/images the two disagreed.

$ ./target/release/oxidex -json $ET/t/images/Geotag.log | rg -i 'FileType|MIMEType'
    "File:FileType": "TXT",
    "File:FileTypeExtension": "txt",
    "File:MIMEType": "text/plain",
    "FileType": "TXT",            <- ungrouped duplicate
    "MIMEType": "text/plain",     <- ungrouped duplicate

Font.dfont was the sharp version: File:FileType "DFONT" beside a bare FileType "ICO", left there by the ICO parser, which the file reaches because ExifTool's Font magic number matches anything starting \0\x01. Nothing downstream could say which of the two was meant.

Roughly forty parsers insert these tags ungrouped while the File:-grouped ones come from extract_file_metadata and add_identity_tags. No step reconciled them, and MetadataMap::merge does no group normalization.

The fix

normalize_identity_tags runs after add_identity_tags and leaves one answer per tag, under File:.

The File: value is the one kept. Both resolvers take it from crate::filetype, generated from ExifTool's %fileTypeLookup, %fileTypeExt and %mimeType; a parser's own string is its private spelling of the same fact at best (WebP where ExifTool says WEBP, Plist where it says PLIST) and a loose magic match at worst. Across the 21 disagreements the File: value is ExifTool's answer 20 times.

The one thing a parser can still contribute is a name where the tables produced none, so a bare FileType fills an absent or Unknown one before being dropped — EXE.elf keeps ELF rather than losing it to Unknown.

MIMEType is deliberately not treated the same way. application/octet-stream reads like a placeholder but is ExifTool's real answer for DR4, VRD, LNK, MOI and the Mach-O family, so overwriting it with a parser's value would replace a correct answer rather than fill a gap.

Verification

Identity sweep over ExifTool's t/images (194 files) against the pinned 13.59 oracle, before and after:

	before	after
File:-group matches	179	179
per-tag matches	563	563
ungrouped duplicates	50	0
contradictory pairs	21	0

The match counts are deliberately unchanged: #644, #648 and #641 already fixed the resolution side, so this is purely the de-duplication that was left over. Zero per-tag regressions.

cargo test --workspace green across 47 targets; clippy and fmt clean.

Test changes

19 assertions in production_wiring_tests.rs read the now-removed ungrouped key and were pointed at File:FileType. Three changed value, each toward ExifTool:

• XML plist: Plist → PLIST
• two .eml fixtures: EML → TXT. ExifTool 13.59 has no EML file type — .eml is absent from %fileTypeLookup and an email reports TXT/txt/text/plain. EML was only OxiDex's name for the parser; the EML: tags those tests already assert are what show the routing worked.

Not in scope

• FileSize has the same duplicate shape on the same files ("785 bytes" vs a bare "785" vs TEXT:FileSize), as do LineCount/WordCount/Newlines against their TEXT: copies.
• XMP.xml reports TXT where ExifTool says XMP. fix(filetype): identify unlisted text files as XML or TXT by content #648's identify_text declines XMP by design; closing that gap means routing <rdf:RDF> content to the XMP parser, which is a coverage change rather than an identity one.
• The 15 remaining sweep differences are the known separate gaps — ELF/Mach-O subtype descriptions, Win32 EXE, JXL Codestream, Extended WEBP, and several MIME-value mismatches.

🤖 Generated with Claude Code