WP_AI_Client_Ability_Function_Resolver::execute_abilities() answers non-ability function calls with a spurious error

[khokansardar]

WP_AI_Client_Ability_Function_Resolver has two methods that scan a message's function-call parts:

• has_ability_calls() guards each part with is_ability_call(), so it only reports parts prefixed with wpab__.
• execute_abilities() does not guard — it calls execute_ability() on *every* function-call part.

For any function call that is not an ability (i.e. a tool handled elsewhere, the normal case when a model is given both Abilities and other tools), execute_ability() returns a FunctionResponse with code => 'invalid_ability_call'. Because providers require a response for every function call, that fabricated error response gets attributed to the other tool, and the real tool never runs.

The two methods should agree: execute_abilities() should skip parts where ! is_ability_call().

Steps to reproduce

1. Build a ModelMessage containing two function-call parts: one wpab__... ability call and one non-ability call (e.g. some_other_tool).
2. Call execute_abilities() on it.
3. Observe the returned UserMessage contains a FunctionResponse for the non-ability call with code => 'invalid_ability_call'.

Expected: only the ability call is answered; the non-ability call is left untouched.

Fix

Add the is_ability_call() guard in execute_abilities() so it matches the parts
reported by has_ability_calls(). Includes a regression test covering a mixed ability / non-ability message.

WP_AI_Client_Ability_Function_Resolver::execute_abilities() ran execute_ability() on every function-call part in a message. Unlike its sibling has_ability_calls(), it did not check is_ability_call() first, so a function call for a tool handled elsewhere (anything not prefixed wpab__) was answered with a fabricated invalid_ability_call error response. Because providers expect one response per function call, that spurious response was attributed to the other tool and the real tool never ran.

Add the is_ability_call() guard so execute_abilities() processes the same parts that has_ability_calls() reports, and add a regression test covering a mixed ability / non-ability message.

Fixes #65504.

Trac ticket: https://core.trac.wordpress.org/ticket/65504

## Use of AI Tools

N/A

[gziolo]

In 62555:

AI Client: Skip non-ability function calls in execute_abilities()

WP_AI_Client_Ability_Function_Resolver::execute_abilities() should only respond to function calls that are ability calls. Previously, non-ability tool calls were passed to execute_ability() and received an invalid_ability_call response, preventing other tool handlers from processing them.

This updates execute_abilities() to mirror has_ability_calls() by checking is_ability_call() before executing, and adds regression coverage for mixed ability and non-ability calls.

Props khokansardar, jigar-bhanushali.
Fixes #65504.