[dspace-9_x] Fix #4734: resolve bitstream download link with UI namespace

[hernanhlagos]

References

• Fixes Bitstream download route fails when DSpace is deployed under a custom context path #4734
• Follow-up to Fix #4734: Normalize contextPath handling in bitstream download route #4735

Description

This PR fixes the bitstream download button in the item edit bitstreams page when DSpace Angular 9 is deployed under a UI namespace / context path, for example /repository.

The fix updates the download button to use [routerLink] instead of [href], matching the behavior already present in dspace-10_x.

Instructions for Reviewers

List of changes in this PR:

• Changed the bitstream download button in item-edit-bitstream-bundle.component.html from [href]="entry.downloadUrl" to [routerLink]="entry.downloadUrl".
• This allows Angular to resolve the download link using the configured base href / UI namespace.
• No REST API changes are required.

This issue occurs when DSpace Angular is deployed under a UI namespace, for example:

ui:
  baseUrl: http://localhost:4000
  nameSpace: /biblioteca

rest:
  baseUrl: http://localhost:8080/repository/server

How to reproduce the issue

1. Configure DSpace Angular with ui.nameSpace: /repository.
2. Start DSpace Angular.
3. Edit an item.
4. Go to the bitstreams/files edit tab.
5. Inspect or click the download button for a bitstream.

Before this change

The rendered link omits the configured UI namespace:

/bitstreams/<uuid>/download

This causes the browser to resolve the URL from the root of the host instead of under /repository.

After this change

The rendered link includes the configured UI namespace:

/repository/bitstreams/<uuid>/download

This matches the behavior already present in dspace-10_x.

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](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/display/DSDOC9x/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).