fix: guard AddPowderPatternDiffraction setup

[vincefn]

Summary

• fix AddPowderPatternDiffraction() so a no-reflections failure does not leave a broken partial component attached to the powder pattern
• add a focused regression test for the empty-range rollback case
• add the required news/94.rst item
• context: Segfault on cleanup after PowderPattern::AddPowderPatternDiffraction() throws "no reflections" (2θ range with zero reflections) vincefn/objcryst#81

Root cause

addppdiffraction() constructed a PowderPatternDiffraction, attached it to the powder-pattern setup path, and then let the diffraction preparation step raise from the no-reflections case. That left the convenience wrapper able to fail after partially wiring the diffraction object into the pattern lifecycle.

Fix

The wrapper now keeps the temporary diffraction component under local ownership during setup, assigns the crystal, prepares it against the target powder-pattern context, and only registers it with the PowderPattern after preparation succeeds. This preserves the expected ObjCrystException for an empty range while preventing the failed component from being retained by the powder pattern.

Regression coverage

Local targeted coverage:

• PYTHONPATH=src python -m pytest -q src/pyobjcryst/tests/testpowderpattern.py -k 'rollback or update_nbrefl'

The new rollback test asserts that AddPowderPatternDiffraction() raises on a no-reflections range and that the powder pattern still reports zero components afterward. The existing test_update_nbrefl case keeps a successful diffraction-add path covered in the same targeted run.

[sbillinge]

@vincefn lgtm. Do you want to roll this towards a new release shortly? Let me know if you want me to do anything.

For the other codes we are starting to migrate from python boost to nanobind to bring them up to latest standards as the python kernel migrates in 3.14 and beyond. Shall we do some of that work on objcryst and pyobjcryst? We have been putting that work on base branches called migration-nano, and could do the same here, in case we break everything.

[vincefn]

Thanks, I'll merge this.

As for migrating for nanobind, I guess we have to, boost starts to show its age. But I have no idea how hard the migration would be (then again with AI maybe all the wrapping and object ownership issues will be handled easily..).

There are a few incoming changes notably from the work of @clemisch (working on large powder diffraction maps automated Rietveld/profile fitting) so maybe it can be done after that has been released. I don't see yet c++ changes in the migration-nano branch.

I'm also wondering if we actually need libobjcryst or if pyobjcryst could directly include objcryst as a git sub-project and compile everything - would save some headaches with conda/pip publications. But we should move that discussion elsewhere.

[sbillinge]

We have done the nanobind migration (undergoing review) for libdiffpy and it is not too bad. We didn't start on pyobjcryst/libobjcryst but if we decide to retire libobjcryst, this would seem to be a good time to do it, when we do this migration.