Accessibility: Use buttons for Add Themes sorting controls

[Sukhendu2002]

This PR fixes the incorrect semantics of the Add Themes sorting controls. These controls perform JavaScript actions but were marked up as links pointing to #. They are now native buttons, providing the expected keyboard and assistive technology behavior.

The JavaScript selectors and CSS have been updated to support the buttons while preserving the existing behavior and appearance.

This resolves the Add Themes-specific part of #26504.

Trac ticket: https://core.trac.wordpress.org/ticket/26504

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props sukhendu2002.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[irozum]

Nice, focused fix — converting the Add Themes sorting controls from <a href="#"> to real <button type="button"> is exactly the kind of scoped, low-risk win ticket #26504 has been looking for, and the JS selector changes from li > a to [data-sort] are a nice touch since they work regardless of the underlying element, keeping the code resilient to future markup changes in this area.

I checked out the branch, ran npm run build:dev (clean) and composer lint:errors on the touched PHP file (no errors); CI is green across the board too. I traced the JS: onSort reads event.target and $(event.target).data('sort'), and since the buttons have no nested markup, event.target still resolves to the button itself, so event delegation isn't broken. The CSS reset (border: 0; background: none; font: inherit;) correctly strips native button chrome before re-adding the border-bottom/hover/focus styling, and the new :focus box-shadow plus transparent outline follows the same Windows High Contrast pattern already used by .filter-links .current. I also grepped for other consumers of .filter-links (Plugin Install, Media list table, updates.js) — none of them are touched by this PR, and the CSS/JS changes here are additive (.filter-links li > a, .filter-links li > button), so those other screens keep working unmodified.

One minor, non-blocking note: this view has no existing JS test harness (no QUnit/e2e coverage for the theme installer's filter/sort behavior either before or after this change), so there's nothing to extend here — just flagging that I didn't find a way to verify the keyboard/focus behavior with an automated test, only by reading the code.