PackageInspector accepts strict-namespace image relationships that the reader's RelationshipType.image does not (declared set ⊋ reader's image set on strict packages)

[kiki830621]

Summary

PackageInspector (3.7.0, PR #141) resolves relationship references and w:drawing elements by namespace and accepts both the transitional and the strict OOXML namespaces (http://schemas.openxmlformats.org/officeDocument/2006/relationships and http://purl.oclc.org/ooxml/officeDocument/relationships), and scanRels recognizes an image relationship by Type.hasSuffix("/image"), which matches the strict Type URI too.

DocxReader's RelationshipType.image (Relationship.swift, .image case) is an exact match on the transitional URL only. So on a strict-conformance package the inspector declares image relationships that never reach WordDocument.images, and can report orphans the reader would never know about.

Direction

Safe direction (the reader's image set ⊆ the inspector's; nothing is hidden), so this is a consistency follow-up, not a mute switch. But "what the reader loads" and "what the inspector declares" are supposed to describe the same package, and a consumer reconciling declaredImageRelationshipRefs against WordDocument.images (che-word-mcp list_images, #199) will see a phantom difference on strict packages.

Options

1. Teach RelationshipType the strict URIs (reader catches up — preferred; strict packages then also load images).
2. Make the inspector's image-type predicate exactly the reader's (RelationshipType.image equality) — narrows the inspector to the reader's blind spot.

Either way the two predicates should be one function.

Evidence

Verify R3 security lens finding S-R3-6 on PR #141 head 92befb9 (PackageInspector.swift relationshipsNamespaces / wordprocessingNamespaces / scanRels vs Relationship.swift:47). Strict packages are rare in practice (0 / 740 in the real corpus), hence LOW.

Source: surfaced during /idd-verify R3 of cluster PR #141 (#137 / #138 / #139), security lens. Refs #137.