xml: check a fragment against the prefixes its ancestors declare

[mgilbir]

Closes the fragment half of the parse-entry-point exemptions. 13 → 9.

The problem

Four parses were exempt from the namespace rule for one reason: they read bytes lifted out of a larger document, whose prefixes are bound by declarations that stayed behind on an ancestor. The part-level rule would reject valid content, so they were excused entirely.

The API had to be prefixes, not URIs

The check tracks declared URIs, because that is what the decoder leaves visible: a bound prefix arrives as its URI, an unbound one as the prefix string itself. A fragment's inherited prefixes are the latter — so an in-scope URI set would have been inert. CheckNamespacePrefixesInScope seeds in-scope prefixes.

Two of the four did not need it

CT_Scenarios.parse and CT_OleObjects.parse rebuild their element with encodeUnknownElement and passed nil — where the sibling call one line above passes the root's prefix map. They were discarding declarations already in hand. They now pass it, and take the in-scope set, because encodeUnknownElement declares only what the start tag uses while inner content is carried across as raw bytes.

One could not be fixed any other way

<pivotCaches><pivotCache cacheId="1" r:id="rId5"/></pivotCaches>

r: is used on a child, so no reconstruction declares it — and these bytes are re-emitted verbatim, so giving them the missing declaration would change what an untouched round trip writes. This is the case the in-scope set exists for.

What remains exempt, and why it should

Six deep copies of this library's own marshal output; the crypto descriptor (not an OPC part); a validation probe that reports decodability as a bool; and one synthesized wrapper — self-contained for w:, but content using another prefix would silently stop parsing and no gate would catch that, so a real check is not traded for a theoretical one.

Verification

The tests hold the line this change could have crossed: an unrelated in-scope prefix does not excuse an unbound one, an empty set behaves exactly like the strict check, a self-contained fragment needs no help, and trailing content is still refused.

gate	result
build / vet	clean
golangci-lint	0 issues
full unit suite	clean
corpus byte-identity	ok, 155s
fuzz, 34 targets (xlsx/pptx/common-xml/chart)	exit 0, no crashers

The repo's own maporder guard caught map-order iteration in the prefix collection on the way in; sorted.