SAZ metadata accepts contradictory XML encoding declarations #3273

Reproduction and observed result

On main 29d3dcb7ea85b3be37cd81e977ae4e09cebdd2fc, Node 24.18.0/npm 11.16.0 and locked dependencies, create an ordinary ZIP-based .saz containing a single raw/1_m.xml:

<?xml version="1.0" encoding="UTF-16"?><Session><Note>café</Note></Session>

Store those bytes as UTF-8, then run rea inspect-web-network-capture <archive.saz> saz --json. REA exits 0 and retains the Session metadata, even though the encoding declaration contradicts the bytes. The same operation also accepts BOM-marked UTF-16LE bytes declaring UTF-8. Python's byte-aware XML parser rejects both original byte inputs as incorrect encoding declarations.

Another fixture declares ISO-8859-1 but stores UTF-8-shaped bytes for café. The declaration-aware byte parser reads café; REA instead reports café without a decoding limitation. This encoding is outside REA's existing UTF-8/BOM-UTF-16 metadata profile and should be refused rather than silently interpreted as a different charset.

Expected behavior and controls

Reject supported encodings with contradictory declarations and explicitly refuse unsupported declared encodings before producing successful metadata Evidence. Preserve consistent UTF-8 and BOM-marked UTF-16LE/BE metadata. All three supported positive controls currently pass, and actual Latin-1 bytes already fail the existing supported-profile gate. Every original archive remains byte-identical after inspection.

All records should remain validated before optional record selection; the same contradiction in an unselected second Session must not become a successful complete-input inspection. This is a passive local-data correctness issue, not a new live-Fiddler or decoder execution capability.

Cause and scope

SazMetadata chooses a decoder solely from the BOM/default UTF-8. Its existing SAX well-formedness check parses the resulting string but does not compare the parsed XML encoding declaration with that byte interpretation. Repair the shared byte/declaration owner before DOM projection; retain the existing malformed-character, DTD, budget, cancellation and cleanup policies.

XML 1.0 section 4.3.3 requires the byte encoding to agree with the declaration and permits refusing unsupported encodings. The existing metadata profile can stay narrow; no new charset support is needed.

Verified with actual compiled CLI and independently parsed original XML bytes on macOS arm64. No repair, Windows/Linux, MCP or current Fiddler UI export is claimed yet. Targeted live searches and the relevant #2884/#3082 diffs show no equivalent repair; closed #2601 concerns XML character/grammar validation and does not validate encoding declarations.