Translate XMLStreamReader creation errors to StreamReadException

[Sahana2524]

XmlFactory._createParser catches only XMLStreamException around createXMLStreamReader:

• non-Woodstox Stax impls (SJSXP, ArrayIndexOutOfBoundsException thrown for invalid ending XML string when using JDK default Stax XML parser #618) parse the XML declaration during reader creation and can throw ArrayIndexOutOfBoundsException on malformed input
• that unchecked exception escapes readValue/readTree instead of a StreamReadException, so callers catching JacksonException never see it
• the sibling paths already translate this (_initializeXmlReader for Wrap Xerces/Stax (JDK-bundled) exceptions during parser initialization #350, the reader.next() adapter for ArrayIndexOutOfBoundsException thrown for invalid ending XML string when using JDK default Stax XML parser #618); the create boundary was the gap

Wrapped it in all four _createParser overloads; the test uses a stand-in factory that throws at reader creation.

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	73.50%	📉 -0.050%
Branches	68.08%	📈 +0.000%

Coverage data generated from JaCoCo test results

[cowtowncoder]

TBH, this sounds like SJSXP bug we should not pave over -- it really should not leak AAOOBEs.

I'll need to think about this a bit...

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	73.56%	📈 +0.000%
Branches	68.08%	📈 +0.000%

Coverage data generated from JaCoCo test results

[Sahana2524]

Agreed, the root cause is SJSXP and ideally it gets fixed there. The reason I went this route is that the next() path already translates the exact same AIOOBE from the SJSXP decoder (Stax2JacksonReaderAdapter, from #618), so createXMLStreamReader() looked like the one remaining boundary where it still escapes as a raw runtime exception. No urgency on my end, happy to adjust if you'd rather handle it differently.

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	73.60%	📉 -0.040%
Branches	68.35%	📈 +0.000%

Coverage data generated from JaCoCo test results

[cowtowncoder]

@Sahana2524 actually I agree with your assessment after thinking it through: this is one-off on construction and there's earlier precedents. Thank you!

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	73.59%	📉 -0.050%
Branches	68.35%	📈 +0.000%

Coverage data generated from JaCoCo test results

[github-actions]

🧪 Code Coverage Report

Metric	Coverage	Change
Instructions	73.63%	📉 -0.010%
Branches	68.40%	📈 +0.050%

Coverage data generated from JaCoCo test results