Abilities API: add execution lifecycle filters to WP_Ability methods

[gziolo]

Summary

Adds four new filters to WP_Ability to give plugins hook points across the execution
lifecycle. Today the only execution-phase hooks are observation-only actions
(wp_before_execute_ability, wp_after_execute_ability); plugins that need to
transform input, modify output, override permission decisions, or short-circuit
execution have no place to do that in core, and have built parallel hook systems
on top.

This PR closes that gap by introducing four filters, three living inside their
owning WP_Ability methods (so they apply consistently across execute(), REST
permission checks, and WP-CLI), and one on execute() itself for orchestration
control.

Filters added

Filter	Where	Purpose
wp_pre_execute_ability	top of execute()	Short-circuit. Returning non-null bypasses the entire pipeline (modeled on rest_pre_dispatch).
wp_ability_normalize_input	inside normalize_input()	Transform input — prompt enrichment, parameter defaulting beyond JSON Schema, caller metadata injection. Returning WP_Error halts execution.
wp_ability_permission_result	inside check_permissions()	Override the registered permission_callback result. Applies consistently across all call sites.
wp_ability_execute_result	inside execute(), after do_execute()	Transform the result before output validation. Can also recover from do_execute() failures by returning a successful value in place of WP_Error.

Pipeline ordering inside execute()

wp_pre_execute_ability  (filter, can short-circuit)
  → normalize_input()   → wp_ability_normalize_input  (filter)
  → validate_input()
  → check_permissions() → wp_ability_permission_result (filter)
  → wp_before_execute_ability  (existing action)
  → do_execute()
  → wp_ability_execute_result  (filter, runs before output validation)
  → validate_output()
  → wp_after_execute_ability   (existing action)
  → return

Schema validation remains the final integrity gate: wp_ability_normalize_input
fires before validate_input(), and wp_ability_execute_result fires before
validate_output(). Filters cannot bypass schema validation except by
short-circuiting via wp_pre_execute_ability, where the caller takes
responsibility for the returned value's shape.

Commits

This PR is split into four atomic commits, one per filter, in lifecycle order.
Reviewers can read commit-by-commit or as a single diff.

1. wp_ability_normalize_input
2. wp_ability_permission_result
3. wp_pre_execute_ability
4. wp_ability_execute_result

Test plan

• npm run env:composer -- format — clean
• npm run env:composer -- lint — clean
• npm run env:composer -- compat — clean
• npm run typecheck:php — 0 errors
• npm run test:php -- --group=abilities-api — 263/263 passing
• Full PHPUnit suite — only unrelated pre-existing failure (Tests_Theme_ThemeDir::test_broken_themes, fails on trunk too)

20 new tests cover:

• Each filter receives the documented parameters.
• Transformation use cases (input rewrite, permission override, result repair).
• Short-circuit semantics for wp_pre_execute_ability (asserts no downstream filter, action, callback fires).
• Ordering: wp_ability_execute_result runs before output validation and before wp_after_execute_ability.
• Failure handling: wp_ability_execute_result receiving WP_Error from do_execute().
• wp_ability_permission_result firing when check_permissions() is called directly (REST/WP-CLI path).
• WP_Error propagation from wp_ability_normalize_input halts the rest of the pipeline.

Trac ticket

https://core.trac.wordpress.org/ticket/64989

Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 4.7 (1M context)
Used for: Planning, implementation, unit tests, commit messages, and PR description.

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

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

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