mcp: widen ability_list sanitizer regex to match WP Abilities API ID grammar

[pluginslab]

From the v0.12.0 MCP endpoint security review (PR #216, finding [Low #6]).

`Settings::update_field()` for the `ability_list` type validates each entry against `^[a-z0-9-]+/[a-z0-9-]+$`. The WP Abilities API itself doesn't strictly constrain ability IDs to that grammar — names like `MyPlugin/list_orders` or `woo/Get-Product` could be valid registrations.

Today, a third-party ability with such a name cannot be allowlisted — the admin ticks the box, hits save, and the sanitizer silently drops it with no UI feedback.

Fix:

1. Confirm the actual WP 6.9 Abilities API ID grammar (check core source / docs).
2. Widen the regex accordingly. Still exclude null bytes, slashes (other than the single separator), control chars.
3. Optional UX: surface a warning toast when an entry is dropped by the sanitizer.

Not a security issue (fails closed), but a correctness gap.

[pluginslab]

Verified — closing as no fix needed.

WP core's `WP_Abilities_Registry::register()` enforces the exact same regex we use:

```php
// wp-includes/abilities-api/class-wp-abilities-registry.php:81
if ( ! preg_match( '/^[a-z0-9-]+/[a-z0-9-]+$/', $name ) ) {
_doing_it_wrong( ... );
}
```

So the set of ability IDs our sanitizer accepts is identical to the set WP allows in the first place. A name like `WooCommerce/list_orders` would have already been rejected by core with `_doing_it_wrong` — it can never reach our allowlist UI.

The reviewer's concern was based on the assumption that WP allowed underscores / mixed case in ability IDs. It doesn't. Our regex is correct.