SD-2279 - fix: floating textbox not rendering

[chittolinag]

Issue

Word sometimes emits DrawingML tags with arbitrary prefixes (e.g. ns6:). Our importer only looked for literal a:graphic/a:graphicData, so it dropped the whole drawing, emitted a passthroughBlock inside the run, and calculateInlineRunPropertiesPlugin crashed with RangeError: Invalid content for node type run.

Proposed solution

Normalize DrawingML lookups by local name in handleImageNode (and helpers) so graphic/graphicData, blips, transforms, etc. are found regardless of prefix; do the same in vector-shape-helpers.

[linear]

SD-2279 BUG: Floating textbox does not render

[github-actions]

All elements and attributes check out against the spec. The PR is a namespace-prefix normalization refactor — instead of hard-coding a: prefixes (e.g. el.name === 'a:graphic'), it now uses local-name matching utilities, which is more robust when parsers emit alternate prefixes like ns6:.

Status: PASS

Every DrawingML element and attribute accessed in this diff is valid per ECMA-376:

• a:lum bright/contrast — correct (§20.1.8.42)
• a:headEnd/a:tailEnd type/w/len — correct (§20.1.8.38, §20.1.8.57)
• a:xfrm rot/flipH/flipV — correct (§20.4.2.43)
• a:picLocks noChangeAspect — correct (§20.1.2.2.31)
• a:grayscl — empty element, no attributes, correct (§20.1.8.34)
• a:lin ang — correct (§20.1.8.41)
• a:gs pos — correct (§20.1.8.36)
• a:path (in gradFill) path attribute — correct (§20.1.8.46)

The findChildByLocalName / hasLocalName utilities are semantically equivalent to the original exact-match lookups for well-formed documents, and handle the alternate-prefix case correctly. The test covering ns6: prefixed nodes is a good addition.

One pre-existing note unrelated to this PR: in extractLineEnds, width and length in the return { type, width, length } are never assigned from the parsed attributes (they'll be undefined). That's not introduced here, but worth a follow-up.