Fix: Preserve related_packages when PUT omits the field

[thales0591]

Related issue: archivematica/Issues#1774

Summary

This PR prevents AIP↔DIP relationships from being unintentionally cleared during reingest. We observed that the DIP is stored with the correct related_package_uuid, but a later AIP update (PUT) wipes related_packages because the field is omitted. The fix preserves existing relationships on PUT when related_packages is not included.

What we observed (logs)

• The DIP storeaip_v0.0 task sends related_package_uuid correctly.
• The Storage Service response already contains related_packages pointing to the AIP.
• Conclusion: the relationship exists right after DIP storage; it is lost later.

Normal ingest flow (works)

• AIP is stored first.
• DIP is stored later and includes related_package_uuid (pipeline store_aip.py).
• Storage Service adds the relationship (self.related_packages.add(...)).
• No later AIP update clears the relationship.

Reingest flow (problematic)

• Reingest runs and produces a new AIP version.
• DIP is stored and the relationship is created (confirmed in logs).
• AIP is then updated via PUT in the Storage Service:
• PackageResource.obj_update → obj_update_hook → finish_reingest
• The PUT payload does not include related_packages.
• Tastypie full-hydrates the object and clears missing ManyToMany fields.
• Since related_packages is symmetric, the DIP loses the reverse link too.

Fix implemented

In PackageResource.obj_update, if the request is PUT and related_packages is not present, we preserve the current relationships:

• Capture related_packages before full_hydrate.
• Restore them after save, this keeps the intended PUT behavior while avoiding unintended data loss.

Alternatives considered

• Preserve related_packages only during reingest (inside finish_reingest).
• Recreate the relationship from the pipeline after reingest completes.
• Reorder the workflow so DIP storage happens after the final AIP PUT.