Enhancement: Include exact post/term slug matches in menu quick search results, ranked first - #14193

Adds exact slug matching to every "Add Items" search surface in the nav menu editor (classic Menus screen, its no-JS fallback, and the Customizer's menu panel), merged ahead of the existing fuzzy title search.

Problem

On large sites with many pages — the reporting use case is a Joomla-to-WordPress migration with 2000+ pages — the "Add Pages" quick search is a fuzzy title search and cannot disambiguate pages that share the exact same title. No search strategy based on titles can fix that; only an identifier orthogonal to the title (the slug) can. There was previously no way to add a menu item by slug (or ID) at all.

A related ticket, #48655 (WP 6.9), already restricted the classic screen's AJAX search to post_title only instead of title+excerpt+content, which cut down on irrelevant matches from body content — but it doesn't help when two pages are titled identically, and it only touched one of three independent search code paths in core.

What this changes

Every search box now checks the query against the post/term slug (exact match, =, not LIKE) in addition to the existing fuzzy title search, with no new UI and no prefix syntax — the same input field is reused. An exact slug match, when found, is always ranked first and deduplicated against the fuzzy results, and takes a slot within the existing result caps rather than being added on top of them.

• src/wp-admin/includes/nav-menu.php
  • _wp_ajax_menu_quick_search() — exact slug lookup for both the quick-search-posttype-* and quick-search-taxonomy-* AJAX branches, via get_page_by_path() / get_terms( [ 'slug' => ... ] ).
  • wp_nav_menu_item_post_type_meta_box() / wp_nav_menu_item_taxonomy_meta_box() — same lookup added to the no-JS fallback forms, which previously had no slug support and no restriction to title-only search at all.
• src/wp-includes/class-wp-customize-nav-menus.php
  • WP_Customize_Nav_Menus::search_available_items_query() — same lookup added to the Customizer's "Add Items" panel. Pagination required care here: the client JS infers "more pages exist" purely from result count, and page 2+'s offset is precomputed from the original page size, so the fix fetches fuzzy results unchanged and trims the tail after merging, rather than shrinking the query limit (which would have desynced the offset math).
• Exact match only, deliberately — no partial/LIKE slug matching, which would just recreate the same disambiguation problem on sites that already use systematic slug prefixes.
• No post ID lookup. Decided against it: nobody memorizes a page's numeric ID, so it wouldn't actually solve the reported problem, and it would add numeric-string ambiguity (is 42 an ID or a slug?) for no real benefit.
• No new filter — the existing wp_ajax_menu_quick_search_args filter is untouched, since the exact-match lookup is a separate call from the filtered WP_Query args.

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

Use of AI Tools

• AI assistance: Yes
• Tool(s): Claude Code
• Model(s): Claude Sonnet 5
• Used for: Investigated the existing search code and scope decision for the exact-slug-match approach (including the Customizer pagination handling), implementation and unit tests.

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.