fix(ui): move pagination data into script tag

[gcgoncalves]

🐛 Bug-fix PR

📌 Summary

1. Define paginationData() once as a global function in admin.js, with all its methods.
2. Replace the inline Jinja2 data in the template with data-* attributes;

Closes #2975

🔁 Reproduction Steps

1. Access the Admin UI
2. Open the browser console
3. Check there are no errors
4. Navigate to the table tabs (mcp gateways, virtual servers, tools...)
5. Check pagination is working correctly (change items per page, switch pages, etc.)

🐞 Root Cause

Jinja was escaping JS content inside a x-data attribute.

💡 Fix Description

Moved the JS object inside a script tag to prevent escaping, then referred to it from the x-data attribute.

🧪 Verification

Check	Command	Status
Lint suite	make lint	✅
Unit tests	make test	✅
Coverage ≥ 80 %	make coverage	✅
Manual regression no longer fails	steps / screenshots	✅

✅ Checklist

• Code formatted (make black isort pre-commit)
• No secrets/credentials committed

[marekdano]

What's Good

1. Correct root cause fix — Moving JS out of x-data attributes eliminates the Jinja2/Alpine escaping conflict entirely. This is a clean separation of concerns.
2. Single definition, multiple instances — The old approach duplicated the full JS object in every pagination_controls.html include. Now there's one paginationData() function shared by all pagination controls.
3. Keyboard listener deduplication — The old <script> block at the bottom of the template registered the keydown listener N times (once per include). Moving it to admin.js inside alpine:init registers it once. This is a meaningful bug fix on its own.
4. query_params handled well — The Jinja2 {% for %} loop for query params is replaced with a data-query-params attribute using | tojson, which is then parsed in init() with defensive error handling.
5. Template is dramatically simplified — pagination_controls.html goes from ~147 lines of mixed JS/HTML/Jinja2 down to ~19 lines of clean HTML data attributes.

Issues & Suggestions

1. ESLint failures noted in the diff view — The WebFetch summary mentions two ESLint issues:
   - Line ~270: formatting issue with object literal line breaks
   - Line ~295: missing braces after if condition (if (prevBtn && !prevBtn.disabled) prevBtn.click();)

Confirm these pass make lint. The single-line if without braces is a style choice — if the project enforces curly, this will fail CI.

2. Keyboard shortcuts target the wrong pagination control when multiple exist — The keydown handler uses document.querySelector('[\@click="prevPage()"]') which always grabs the first matching button on the page. If there are multiple pagination controls (tools, servers, resources tabs), arrow keys will always paginate the first one regardless of which tab is active. This is a pre-existing bug carried forward, but worth noting for a follow-up.

The approach is sound and addresses the root cause correctly. The PR is still in Draft status, so presumably the ESLint issues will be resolved before marking it ready. The keyboard shortcut scoping is pre-existing and shouldn't block this PR, but it would be good to track as a follow-up.

Recommendation: Approve once ESLint issues are resolved and CI is green. The template simplification and listener deduplication are clear wins beyond just fixing the console errors.

[gcgoncalves]

Keyboard shortcuts target the wrong pagination control when multiple exist — The keydown handler uses document.querySelector('[@click="prevPage()"]') which always grabs the first matching button on the page. If there are multiple pagination controls (tools, servers, resources tabs), arrow keys will always paginate the first one regardless of which tab is active. This is a pre-existing bug carried forward, but worth noting for a follow-up.

@marekdano Where do we have multiple pagination controls on the same page? I want to test this issue. I added a bit to lock the controls to the last interacted with when there are more than one in a page.

[marekdano]

Keyboard shortcuts target the wrong pagination control when multiple exist — The keydown handler uses document.querySelector('[@click="prevPage()"]') which always grabs the first matching button on the page. If there are multiple pagination controls (tools, servers, resources tabs), arrow keys will always paginate the first one regardless of which tab is active. This is a pre-existing bug carried forward, but worth noting for a follow-up.

@marekdano Where do we have multiple pagination controls on the same page? I want to test this issue. I added a bit to lock the controls to the last interacted with when there are more than one in a page.

This issue is not introduced in this PR. The issue is already in the main. I've raised a new one #3040.

[marekdano]

Since the lint issues are fixed and a new issue #3040 has been raised

LGTM 🚀

[crivetimihai]

Review: Move pagination data into script tag

Clean architectural improvement that eliminates duplicated inline JavaScript.

What's good

• Global paginationData() function: Replaces N inline x-data blocks with a single global definition. Each instance reads its config from data-* attributes via init().
• Keyboard navigation fix: The old per-include <script> block registered the ArrowLeft/ArrowRight listener N times (once per pagination control). Now it's registered once globally with _lastActivePaginationRoot tracking.
• Query params registry: window._paginationQuerySetters elegantly handles per-section query params without embedding Jinja in the global JS.
• Data- attribute pattern*: Clean separation between server-rendered data and client-side behavior.

Minor

• The rfc9728-compliance.md link change (GitHub permalink → relative path) is unrelated to pagination — might be cleaner as a separate commit, but not a blocker.

[gcgoncalves]

I addressed rfc9728-compliance.md as part of this PR because it was breaking CI. 😬

[crivetimihai]

Thanks @gcgoncalves — moving pagination data into a script tag is a cleaner approach than embedding it inline. Good separation of concerns.

[crivetimihai]

Reopened as #3155. CI/CD will re-run on the new PR. You are still credited as the author.