Fix #61644: Added support for invalidating application password by passing app_id in the API request

[yashyadav-mo]

Core Track Ticket: https://core.trac.wordpress.org/ticket/61644

Problem
Application passwords can currently only be revoked through the REST API by their internal uuid or by deleting all passwords for a user. For clients that only know their own app_id, there is no supported way to invalidate the matching credentials programmatically. This becomes a security concern because newly created application passwords are returned once and may end up exposed through logged URLs or other downstream logging systems, while the client still lacks a direct way to revoke them by its known identifier.

Root cause
WordPress stores both a per-password uuid and an optional application-provided app_id, but the delete flow is only wired to the password uuid. The collection delete endpoint only supports deleting all application passwords, and the internal helper layer had no delete-by-app_id capability. Although app_id is exposed in the REST schema, it was not usable as a revocation key.

Solution
Extend the existing collection delete endpoint to accept an app_id query parameter and revoke all application passwords for the target user that match that app_id. This keeps the existing single-item DELETE .../ route unchanged, preserves the collection delete response shape of deleted and count, validates app_id as a UUID, and adds an internal WP_Application_Passwords helper to remove all matching records while continuing to fire the existing wp_delete_application_password action for each deleted password. Focused REST API tests were added to cover matching deletes, multiple matches, zero matches, invalid app_id, and unchanged delete-all behavior.

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

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.