Add ability to delete bundles in file administration

[alijaber-atmire]

References

• Fixes Add ability to delete bundles in file administration #5014
• Requires Add bulk delete PATCH operation for bundles DSpace#12150
• Builds on Edit bitstream page refactor #4102

Description

Adds bundle-level delete on the item Edit bitstreams page: curators can mark a whole bundle for removal, undo before save, and submit so the UI removes bundles (and their bitstreams) through the REST API. Bundle loading and submit flow are aligned with BundleDataService and cache invalidation so the list refreshes after deletes.

Instructions for Reviewers

List of changes in this PR:

• Item bitstreams edit: per-bundle actions to mark a bundle for removal, show a clear “will be deleted” state, disable drag/upload for that bundle, and undo removal before save.
• Submit flow: ItemBitstreamsService.removeMarkedBundlesAndBitstreams issues bulk bundle removal (JSON Patch remove operations on /bundles/{id} via BundleDataService.removeMultiple) alongside existing bitstream deletions; success/error notifications distinguish bundles-only, bitstreams-only, or both.
• Data layer: BundleDataService.removeMultiple sends the patch to the bundles collection endpoint; item bitstreams page uses BundleDataService.findAllByItem for bundle lists and invalidates the item’s bundles link after successful saves.

How to test / review

1. Deploy this UI against a REST build that includes DSpace#12150.
2. As a user with permission to edit item bitstreams, open an item → Edit → Bitstreams (file administration).
3. Use Remove bundle on a non-essential bundle; confirm the row shows the removal warning and upload/drag are disabled.
4. Use Undo and confirm the bundle returns to normal.
5. Mark one or more bundles for removal (and optionally remove individual bitstreams in other bundles), click Save; confirm success notification, bundles disappear, and removed bitstreams are gone after refresh.
6. Regression: reorder bitstreams (drag), upload to a bundle, and delete single bitstreams still behave as before.

Checklist

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.