Add category support to client package

[emdashcodes]

This PR adds some basic category registration and filtering functionality to the @wordpress/abilities client package, allowing developers to filter abilities by category through the JavaScript API. This addresses some of the feedback highlighted in #102 (review).

What's Changed

• Added required category: string field to the Ability interface and store
• Updated getAbilities() API function to accept an optional category parameter through args object
• Implemented client-side category filtering in store selectors

Tests

• Updated all existing tests to include category field
• Added tests for category filtering in selectors
• Added tests for empty/non-existent category handling

Documentation updates

• Added missing registerAbility documentation
• Added category parameter documentation
• Added example for category filtering

Not Addressed in this PR

• One limitation of this PR is that we do not load categories from the server for validation, because we would need to add a REST API endpoint for fetching categories. Is this something we would be interested in? If we introduce categories over REST and a category does not opt into the REST API, it wouldn't get exposed to the client anyway, so that is something to consider. I can work on this in a follow-up, but want to make sure that's the direction we want to take first.
• This PR also does not introduce any client-specific methods for registering new categories. Because of the larger client/server separation, it's not clear to me how these two registries are supposed to work together anymore, as we basically end up with two separate registries. In my original mental model of how things worked, these registries were one and the same.

Testing Instructions

• Run npm run test:client
• Make sure all tests pass
• Make sure that you have a few test abilities registered, server-side and/or client-side, which you can see examples of in the previous client PRs: Add client-side package for Abilities API #60). To correctly expose server-side abilities, make sure to set meta.show_in_rest to true

		'meta'        => array(
			'show_in_rest' => true,
		),

• Update any of those to pass in a category.
• Now test running and filtering by various different parameters depending on the abilities you have registered.
  For example, I have some server and client abilities, and I can filter by navigation:

  const nav = await wp.abilities.getAbilities({category: 'navigation'});
  console.log('Navigation:', nav.map(a => a.name));

• Output all your registered categories and abilities

const summary = {};
const abilities = await wp.abilities.getAbilities();

for (const ability of abilities) {
  const category = ability.category;

  if (!summary[category]) {
      summary[category] = {
          Category: category,
          Abilities: []
      };
  }

  summary[category].Abilities.push(ability.name);
}

for (const [category, data] of Object.entries(summary)) {
  console.log(`\n${category}:`);
  console.log(data.Abilities.join(', '));
}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.65%. Comparing base (2be5d17) to head (cf2e14e).
⚠️ Report is 1 commits behind head on trunk.

Additional details and impacted files

@@             Coverage Diff              @@
##              trunk     #114      +/-   ##
============================================
+ Coverage     86.48%   86.65%   +0.17%     
  Complexity      148      148              
============================================
  Files            18       18              
  Lines           969      982      +13     
  Branches         86       92       +6     
============================================
+ Hits            838      851      +13     
  Misses          131      131              

Flag	Coverage Δ
javascript	93.04% <100.00%> (+0.41%)	⬆️
unit	84.70% <ø> (ø)

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

☔ View full report in Codecov by Sentry.
📢 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.

[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: emdashcodes <emdashcodes@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>

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

[gziolo]

@emdashcodes, everything looks great from my perspective. This bring the client and server implementation closer to each other after the mandatory category got introduced. As noted in the feedback, @galatanovidiu is working in #115 on adding filtering capabilities on the server, so I added a commit to account on the same shape on the client. This way we should have the interfaces open for further extension with not risk of backward incompatibilities.

I'm approving this PR, but since I added new commits that change some code paths substantially, I would appreciate some sanity check.

[emdashcodes]

Your two changes look good to me. I did some testing on it this morning as well. Thanks for handling it!