Fix Turbo Frames pagination bug

[jazairi]

Why these changes are being introduced:

Navigation past page 2 in search results is broken due to Turbo Frame state management issues. Pagination controls were outside the Turbo Frame, causing full page reloads that lost tab context and broke the pagination flow.

Additionally, Primo API has practical limits around 960 records (or thereabouts), despite claiming millions of results and a recommended offset limit of 2,000 and a hardcoded limit of 5,000. This leads to inconsistent behavior at high page counts (errors, timeouts, etc).

Relevant ticket(s):

• USE-95
• USE-110

How this addresses that need:

• Move pagination controls inside the `search-results`` Turbo Frame to maintain state during navigation.
• Add data-turbo-action='advance' to pagination links for proper URL updates and browser history management.
• Add `rel='nofollow'`` to pagination links to prevent bot crawling.
• Set PRIMO_MAX_OFFSET at 960 based on real-world API testing.
• Implement continuation page for Primo results beyond pagination limits.
• Consolidate result count display logic to show `10,000+`` for all sources when appropriate.

Side effects of this change:

• Pagination now uses AJAX updates instead of full page reloads, providing faster navigation. (This is marginal given how slow the Primo API is.)
• Users will see a "Continue in Search Our Collections" page when reaching Primo's practical pagination limits. It's notable that Primo UI has the same bug as the Search API, so they will continue to experience frustration at higher page counts regardless of which interface they use.
• The URL updates provided by data-turbo-action='advance' also fixes USE-110 (ensuring consistent browser state).
• Some autoformatting applied by VSCode around integers (e.g., 10000 becomes 10_000).
• I have serious concerns about the Primo Search API performance. It is so slow that it times out occasionally after 60 seconds. This makes pagination an inherently poor user experience, as the problem seems to get worse at higher page numbers. I strongly urge us to reconsider making Primo the default tab. If that is not an option, we should evaluate creative workarounds. (E.g., perhaps a higher per-page count would dissuade users from using pagination.) Caching alone is unlikely to help in this case.

Developer

Accessibility

• ANDI or WAVE has been run in accordance to our guide.
• This PR contains no changes to the view layer.
• New issues flagged by ANDI or WAVE have been resolved.
• New issues flagged by ANDI or WAVE have been ticketed (link in the Pull Request details above).
• No new accessibility issues have been flagged.

New ENV

• All new ENV is documented in README.
• All new ENV has been added to Heroku Pipeline, Staging and Prod.
• ENV has not changed.

Approval beyond code review

• UXWS/stakeholder approval has been confirmed.
• UXWS/stakeholder review will be completed retroactively.
• UXWS/stakeholder review is not needed.

Additional context needed to review

Please test USE and GeoData.

Code Reviewer

Code

• I have confirmed that the code works as intended.
• Any CodeClimate issues have been fixed or confirmed as
  added technical debt.

Documentation

• The commit message is clear and follows our guidelines
  (not just this pull request message).
• The documentation has been updated or is unnecessary.
• New dependencies are appropriate or there were no changes.

Testing

• There are appropriate tests covering any new functionality.
• No additional test coverage is required.

[coveralls]

Pull Request Test Coverage Report for Build 18945735539

Details

• 58 of 58 (100.0%) changed or added relevant lines in 6 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.08%) to 98.284%

---

Totals
Change from base Build 18945689052:	0.08%
Covered Lines:	859
Relevant Lines:	874

---

💛 - Coveralls