fix: using new eperson and group on init page instead of cached

[Emil-Domagala-pcg]

References

Fixes #6192
Fixes #3713 (to be confirmed)

Description

Fix stale group names displayed in the Bitstream Resource Policies table after changing a policy's group.

The resource policy list now explicitly re-requests the linked eperson and group data instead of using cached versions, ensuring that the table immediately displays the current group information after saving a policy.

Instructions for Reviewers

List of changes in this PR:

• Updated ResourcePoliciesComponent.initResourcePolicyList() to disable cached versions for the eperson and group links.
• Configured both links with reRequestOnStale: true so that stale linked data is refreshed when loading resource policies.
• This ensures that the Bitstream Policies table displays the updated group name immediately after a policy group is changed.

How to test

1. Create an Item with a Bitstream.
2. Go to Administer → Bitstreams → Edit for the Bitstream.
3. Select Edit bitstream's Policies.
4. Edit an existing Resource Policy.
5. Change only the policy group to a different group.
6. Save the policy.
7. Verify that, after returning to the Bitstream Policies page, the updated group name is displayed immediately.
8. Reload the page and verify that the displayed group remains unchanged and correct.
9. Repeat the test while changing both the policy name and policy group and verify that the updated group is displayed consistently without stale data being shown.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• 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 follows all coding best practices based on the [Code Conventions Guide](../CODE_CONVENTIONS.md)
• My PR **passes **[ESLint](https://eslint.org/) validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes [TypeDoc](https://typedoc.org/) 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](https://wiki.lyrasis.org/display/DSPACE/Code+Testing+Guide).
• My PR **aligns with **[Accessibility guidelines](https://wiki.lyrasis.org/spaces/DSDOC10x/pages/408944958/Accessibility) 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](https://github.com/DSpace/DSpace/blob/main/LICENSE) based on the [Licensing of Contributions](https://wiki.lyrasis.org/display/DSPACE/Code+Contribution+Guidelines#CodeContributionGuidelines-LicensingofContributions) 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](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue).

[lgeggleston]

Hi @Emil-Domagala-pcg, thank you for noting and providing a fix for this! Adding to a project board for reviewers to take a look.

I've tentatively linked this as fixing #3713 as well - which includes the same issue with editing bitstream policies. However, it outlined the same issue occurring when editing the policy for the item as a whole. So just to check, would this fix apply to editing the item policy as well? Thanks!