Fix Namer tool detection of exact and near-exact existing plugins

[NoumaanAhamed]

Description

Fixes #1386.

When using the Plugin Check Namer tool, the AI models (similar_name query) sometimes fail to detect already-published plugins that exist in the WordPress.org Plugin Directory (such as exact or near-exact slug matches). As reported in #1386, evaluating a live plugin like "LessFlux Image & Video Optimizer – WebP, AVIF, CDN & Lazy Load" previously returned "Generally Allowable" without flagging the existing less-flux plugin conflict.

Workaround & Solution

To ensure reliable detection of existing plugins without relying solely on AI model training data cutoffs:

1. Direct WordPress.org API Query: Added query_wordpress_org_directory() in AI_Check_Names to programmatically check candidate slugs and top search matches via WordPress core's plugins_api().
2. Context Enrichment: Merges live directory matches into the AI build_similar_name_context() so the pre-review model evaluates against verified existing plugins on WordPress.org.
3. Verdict Override: If an exact match or near-exact slug collision is confirmed via the directory check (is_exact_match), possible_naming_issues is automatically flagged (true) along with a clear explanation linking directly to the conflicting WordPress.org plugin page.
4. UI Output: Populates confusion_existing_plugins with both direct API matches and AI-suggested matches for the review interface.

---

Testing Instructions

1. Navigate to Tools > Plugin Check in WP Admin and select the Namer tab.
2. Enter the tested name:
   LessFlux Image & Video Optimizer – WebP, AVIF, CDN & Lazy Load
3. Click Evaluate name.
4. Verify that the Namer tool now flags possible_naming_issues as true and displays the existing WordPress.org plugin match under confusion_existing_plugins.

AI Usage Disclosure

• This PR was created without the help of AI tools
• This PR includes AI-assisted code or content
  If AI tools were used, please describe how they were used:
  Used Claude Opus 4.6 for code review, identifying the root cause (single-word search limitation), and refining the implementation.

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

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: NoumaanAhamed <mohamedahamed@git.wordpress.org>
Co-authored-by: davidperezgar <davidperez@git.wordpress.org>
Co-authored-by: tushar-addweb <tusharaddweb@git.wordpress.org>

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

[NoumaanAhamed]

Updated check_directory_search_matches to search all significant slug parts instead of only the first. Previously "Akismet Pro Antispam" only searched "akismet", now it also searches "antispam", which reliably returns Akismet from the WordPress.org API.

[davidperezgar]

Hello, I've used codex and it found this:

• includes/Traits/AI_Check_Names.php:L53: 🔴 bug: parse_json_response() only returns JSON containing possible_naming_issues, a field the similar_name schema forbids. As a result, AI-suggested matches are always discarded and never reach the UI. Use a generic JSON decoder for this response.

• includes/Traits/AI_Check_Names.php:L151: 🟡 risk: every “significant” word triggers another query_plugins call, on top of up to four plugin_information calls; a long name can block the AJAX request with many sequential HTTP requests. Cap/batch the searches and cache the result.

[NoumaanAhamed]

Hey @davidperezgar good catch, Both addressed:

1. parse_json_response bug -> Confirmed. The method gate-checked for possible_naming_issues,
   a field the similar_name schema doesn't have. AI-suggested matches were silently discarded.
   Removed the key check

2. Unbounded search queries -> Capped extra keyword queries at 3 (total worst-case: 4 slug
   lookups + 1 full-name search + 3 keyword searches = 8 HTTP calls). Previously a long name
   could generate 11+.