Abilities Explorer: support custom providers in the filter dropdown and statistics

[azizulhasan]

What?

Closes #883

Makes the Abilities Explorer treat custom providers (set via an ability's meta['provider']) as first-class citizens:

1. The provider filter dropdown is built dynamically, so custom providers become selectable filter options.
2. The overview statistics count abilities by their origin (Core/Plugin/Theme), so an ability with a custom provider label still counts in its origin bucket instead of disappearing from the stat cards.

Why?

Ability_Handler::detect_provider() already supports custom providers via meta['provider'], and get_provider_label() deliberately passes unknown provider names through — the Provider column shows them and the ?provider= query arg filters correctly. But the provider <select> in Ability_Table::extra_tablenav() was hardcoded to all/Core/Plugins/Theme, so custom providers could never be selected in the UI. See #883.

The stat cards had the mirrored problem: get_statistics() only counted the three hardcoded buckets, so any ability with a custom provider label silently vanished from every card (only Total stayed correct). Rendering a card per custom provider would not scale — a site with ten such plugins would get ten extra cards — so the cards stay Core/Plugins/Theme and the counting becomes origin-based instead.

How?

Follows the same approach as the dynamic category filter added in #355 (get_unique_categories()):

• New Ability_Table::get_unique_providers() — known origins (Core, Plugin, Theme) first in canonical order, custom providers appended alphabetically.
• The three hardcoded <option> tags become a loop, labelled via the existing Ability_Handler::get_provider_label(). This also makes the dropdown label ("Plugin") consistent with the Provider column, which used the singular while the old dropdown said "Plugins".
• New Ability_Handler::detect_origin() holds the prefix-based Core/Plugin/Theme detection; detect_provider() returns meta['provider'] when set and falls back to the origin. Formatted abilities expose a new origin field and get_statistics() counts by it — the by_provider array keys are unchanged, so Admin_Page needs no changes.
• Integration tests: new Ability_TableTest covers get_unique_providers() with and without a custom provider (this also covers the line the Codecov report flagged), and a new Ability_HandlerTest case asserts a custom-provider ability still increments its origin bucket in the statistics.

Sites without custom providers see no change anywhere (same four dropdown options, same counts). The accessible label added in #642 is preserved.

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Fable 5
Used for: drafting the implementation and this PR description under my direction; I reviewed the code and tested it on a live site before submitting.

Testing Instructions

1. On a site with the plugin active, visit Tools → Abilities Explorer: the provider dropdown shows all/Core/Plugin/Theme and the stat cards show the same counts as before.
2. Register an ability whose meta includes 'provider' => 'My Plugin' (e.g. via wp_register_ability()).
3. Reload the Explorer: the dropdown now contains a "My Plugin" option; selecting it and clicking Filter lists exactly the abilities with that provider.
4. The stat cards are unchanged by the custom label: the ability still counts under Plugins (previously it dropped out of all three cards).

Tested on WordPress 7.1-beta1 with 112 registered abilities, 82 of them carrying a custom provider: the dropdown gains the custom option and filters to exactly those 82, and the stat cards read Core 6 / Plugins 106 / Theme 0 — identical to the counts before the custom labels were applied.

Changelog Entry

Changed - The Abilities Explorer provider filter dropdown is now built dynamically and includes custom providers, and the overview statistics count abilities by origin so custom-provider abilities remain in their Core/Plugins/Theme bucket.

[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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: azizulhasan <hasanazizul@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>

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

[codecov]

Codecov Report

❌ Patch coverage is 95.83333% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 79.83%. Comparing base (6dcd0ab) to head (40d0a75).
⚠️ Report is 8 commits behind head on develop.

Files with missing lines	Patch %	Lines
...udes/Experiments/Abilities_Explorer/Admin_Page.php	0.00%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##             develop     #884      +/-   ##
=============================================
+ Coverage      78.44%   79.83%   +1.38%     
- Complexity      2454     2475      +21     
=============================================
  Files            104      104              
  Lines           9925    10006      +81     
=============================================
+ Hits            7786     7988     +202     
+ Misses          2139     2018     -121     

Flag	Coverage Δ
unit	79.83% <95.83%> (+1.38%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dkotter]

This PR works as described though there are a few pre-existing issues that we should look to fix here I think:

1. We don't properly sanitize the provider name when we use it as a class. So if I set a custom provider as WordPress AI, the class we add ends up being ability-provider-wordpress ai when it should instead be ability-provider-wordpress-ai
2. We don't properly style the custom provider pill:

And just as a personal opinion, not sure what the benefit is of this custom provider meta. I know that's a pre-existing thing but could be worth a discussion on maybe just removing that.

Seems odd to me to have that show in the Providers dropdown and show as a Provider pill but doesn't actually show in the top statistics. And then it's weird to have custom providers bucketed in the Plugins section of the statistics but if I filter by Plugin, it doesn't show. Just various inconsistencies like those that may be worth fixing or just removing the support all together.

[azizulhasan]

Thanks for the review @dkotter — all three points are addressed in 40d0a75:

1. Sanitization — the pill class is now built with sanitize_title(), so a provider of WordPress AI produces ability-provider-wordpress-ai. Fixed in both Ability_Table::column_provider() and the detail view in Admin_Page.php, which had the same issue.

2. Custom pill styling — the neutral pill styles (background/border/color that -plugin/-theme used) moved onto the base .ability-provider class, so any custom provider now renders as a proper pill; -core still overrides with its blue variant. Since custom provider names are arbitrary, styling the base class is the only approach that covers every possible label.

3. Consistency — the known-origin filters (Core/Plugin/Theme) now match by origin, so filtering by "Plugin" includes abilities that carry a custom provider label — consistent with the statistics, which count by origin. Filtering by a custom provider matches its exact label. New integration test test_provider_filter_matches_origin_for_known_providers covers both directions.

On keeping vs. removing the support: this PR now cleanly splits the two concepts that were previously conflated in one field — origin (Core/Plugin/Theme, derived from the ability name) drives the stat buckets and the known filters, while the meta['provider'] label only affects the pill text and adds a filter option. That's what caused the inconsistencies you listed, and they shouldn't be reproducible on this branch: on a test install with ~82 custom-labelled abilities, filtering by "Plugin" now returns 106 items (matching the "Plugins" stat card exactly), and filtering by the custom label returns only those 82.

The value I see in the label is attribution — on a busy site the Explorer can list 100+ abilities, and "which plugin exposed this capability to the AI" is a real trust/debugging question that a wall of identical "Plugin" pills can't answer. get_provider_label() has passed custom labels through since 0.4.0, so plugins may already rely on it. That said, it's your call — if you'd prefer to drop the label pass-through entirely rather than support it, I'm happy to rework the PR in that direction instead.