fix: enable weights_only=True in torch.load for secure state loading

[RinZ27]

Description

Enable weights_only=True for specific torch.load calls in data modules and metrics where only tensors or state dicts are being loaded. This reduces the security surface by preventing arbitrary code execution when loading these files.

Related Issue

Related to #592

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

I've reviewed the loading logic in diffuser_distillation_data_module.py and aesthetic_laion.py to ensure they only load supported data types (tensors, dicts, strings). Everything looks green and compatible with weights_only=True.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

Additional Notes

While src/pruna/engine/load.py still requires weights_only=False for loading full model objects, I've opted to fix these specific instances where it's safe and beneficial. I've also opened a separate issue #592 to discuss a longer-term architectural improvement for model persistence.

[sdiazlor]

Thank you for the PR @RinZ27! I've run the tests :)

[github-actions]

This PR has been inactive for 10 days and is now marked as stale.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric	Results
Complexity	0
Duplication	0

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[RinZ27]

Thanks for the patience @sdiazlor. Just finished rebasing onto the latest main and cleared out the conflicts. Everything should be clean now and ready for another check whenever you have a moment.

[github-actions]

This PR has been inactive for 10 days and is now marked as stale.

[RinZ27]

@sdiazlor Just a quick ping as the stale bot kicked in. Everything is rebased and conflicts are cleared, so it's ready for a final look whenever you have a moment.

[github-actions]

This PR has been inactive for 10 days and is now marked as stale.

[RinZ27]

Hey @begumcig, just giving this a quick nudge since the stale bot reached out. Been following the discussion in #632 about the broader architectural shift towards safetensors and fallback logic.

Merging this now seems like a solid interim step because it targets isolated metrics and data modules where the loading logic is already predictable. Since @sdiazlor already gave it a green light, I think we can safely harden these specific paths without impacting the larger refactoring efforts for the engine.

Let me know if you’d prefer me to hold off until the unified save/load logic is ready, or if we can push this through as a quick win for those specific modules.