Add support for new meta.public flag #9

WordPress Core ticket #65568 introduces in version 7.1 meta.public as the high-level client-exposure setting, with channel-specific settings taking precedence.

In 7.1 WP Core resolves the cascade before get_meta_item() returns, so show_in_rest already reports effective REST exposure and the command stays correct as is. The gap is that meta.public itself is invisible. There is no public field and no way to tell whether REST exposure came from the high-level flag or the channel flag, which matters as soon as an operator needs to change it. On 6.9 and 7.0 the flag is inert in WP Core, so an ability written against 7.1 produces identical CLI output on every supported version while its actual reachability differs.

Affected surface

Exposure shows up in three documented places today. wp ability list offers show_in_rest as an optional field and a --show-in-rest=<bool> filter. wp ability get includes it among the default fields, so it prints on every call. The parent wp ability page also carries an example that names the field explicitly.

Those pages are generated from the inline command documentation, so the reference updates land in the same PR as the code.

run, exists, can-run, and validate expose nothing about REST or client channels and should stay that way. can-run answers a permission question, which is separate from client exposure.

Scope

Add public as an optional field on list and a default field on get, ordered before show_in_rest. Add a --public=<bool> filter to list.

Core resolves meta.public into the channel flags at registration, so --show-in-rest keeps working against effective exposure without extra logic here. Nothing in this package should reimplement the precedence rules.

wp ability list keeps listing every registered ability regardless of exposure. WP-CLI runs with full trust and its job is to report what is registered, including abilities deliberately hidden from REST and MCP. These flags are display and filter concerns here, not access control.

Open questions

1. Should public render tri-state (1/0/empty) the way readonly and friends already do through format_annotation()? Empty would mean the ability never declared the flag. Note that show_in_rest cannot carry the same distinction anymore, since Core collapses declared and inherited into one resolved value before the command reads it.
2. meta.public only exists in 7.1. On 6.9 and 7.0 the field renders whatever the ability declared while REST exposure does not follow it, which is the confusing case. A WP_CLI::debug() note on those versions may be worth it.
3. Worth adding a raw meta field to wp ability get, mirroring the one wp ability category get already has? It is the only way to see channel-specific settings like meta.mcp.public.

References

Slack thread starting from this message. Related PR in MCP Adapter showing how this hits plugins built on the Abilities API: WordPress/mcp-adapter#254, which also documents a flag resolution ordering trap.