Support multiple search instances on a single page (9.x)

[alijaber-atmire]

References

• Fixes Search components only partially support multiple instances on a single page #5738

Description

Extends the per-search-instance prefixing (currently only applied to sort and pagination) to all remaining search route and query parameters, so multiple search components can coexist on a single page without interfering with each other.

Instructions for Reviewers

This builds on the existing mechanism that prefixes sort/pagination params with a unique search-instance identifier, and applies the same approach to every other search parameter.

List of changes in this PR:

• Added a searchInstanceId to SearchConfigurationService and helper methods to build/read instance-scoped parameters: getSearchInstanceParam, getCurrentSearchInstanceParam, getCurrentSearchInstanceQueryParam, getSearchInstanceFilterParam, getCurrentSearchInstanceFilterParam, and getSearchInstanceFilterParamPrefix.
• Updated getCurrentConfiguration, getCurrentScope, getCurrentQuery, and getCurrentDSOType to resolve their values from instance-prefixed route/query parameters (with a fallback to the legacy unprefixed parameter for backwards compatibility).
• Updated SearchFilterService and SearchService to read/write the f.xxx filter parameters and view using the instance prefix.
• Updated the search UI components that emit search params — search.component, search-form.component, search-results.component, search-settings.component, search-switch-configuration.component, search-navbar.component, search-page.component, configuration-search-page.component, themed(-configuration)-search.component, the facet/range filter option components, and object-collection.component — to use the instance-prefixed parameter names.
• Updated the relation-lookup-modal search/selection/external-source tabs, recent-item-list, my-dspace-configuration.service, and my-dspace.guard to use the new instance-scoped params.
• Updated specs and the search-configuration-service/pagination-service test stubs accordingly.

How to test:

1. Build and run the UI (yarn start / npm start).
2. Render a page containing two independent search components (e.g. two configured discovery searches).
3. In one component, change the query, scope, configuration, view mode, dsoType, and apply facet/range filters.
4. Verify the URL params for that component are prefixed with its instance id (e.g. <id>.query, <id>.f.author, <id>.configuration) and that the second search component is unaffected.
5. Confirm a single-search page (default instance id) still behaves as before, including legacy unprefixed URLs continuing to work.

Checklist

• My PR is created against the main branch of code — N/A: this is a version-specific PR targeting dspace-9_x (the bug is being fixed on the 7.6/9.x/10.x lines).
• 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.