Navigation: Give imported classic menus distinct titles - #85443

What?

Closes #39200.

Give each newly imported classic menu an available Navigation menu title. Importing Primary twice creates Primary and Primary 2 instead of two Navigation menus named Primary.

Why?

The classic-menu converter supplies the classic menu name to useCreateNavigationMenu, which previously skipped the existing default-title generator whenever a name was supplied. Repeated imports therefore saved indistinguishable names. The existing automatic naming algorithm could also select an already used suffix when names had gaps.

How?

Allow the title generator to receive a preferred title and use it for every Navigation menu creation. Wait for both draft and published menus, then select the first available exact title using numeric suffixes. Names that merely share a prefix do not cause a collision. Existing template-area naming, preview behavior, block serialization, post status and save flow are preserved; manually renaming an existing menu is unaffected.

The regression tests exercise the real classic-menu converter, creation hook, title generator and core-data registry, with mocked REST transport at the boundary. They cover sequential imports, draft and published collisions, suffix gaps, literal numeric suffixes, escaped titles, asynchronous resolution, template-area fallback and preview/error controls.

Testing Instructions

1. Create a classic menu called Primary with at least one link.
2. Insert a Navigation block in the editor and open its menu selector.
3. Choose Primary under Import Classic Menus.
4. Open the selector and import the same classic menu again.
5. Confirm the two imported Navigation menus have distinct names (Primary and Primary 2) and retain the same links.
6. With Primary, Primary 2 and Primary 4 already present as draft or published Navigation menus, repeat the import and confirm the new name is Primary 3.

Testing Instructions for Keyboard

Select the Navigation block, use Tab to reach its menu selector and press Enter. Use the arrow keys to choose the classic menu under Import Classic Menus and press Enter. Repeat the import and check the distinct menu names. No controls or keyboard handlers are changed by this patch.

Automated validation

• The final regression file against unchanged source: six expected failures for missing naming/resolution behavior, with four unchanged controls passing. The same test file passes after the fix.

• npm run test:unit -- packages/block-library/src/navigation --sequence.seed=190023: 19 files and 232 tests pass.

• npm run test:unit:conventions: passes.

• Changed-file npm run lint:js: passes.

• npm run typecheck -- packages/block-library/tsconfig.json: passes.

• npm run build: passes.

• After merging trunk on October 24, the Navigation suite, changed-file lint, block-library typecheck, changelog validation and full build pass again. The Entity Fields/Actions API, REST controller and preload subset also passes on native PHP 8.3 (219 tests); this does not substitute for the Linux PHP 7.4 CI job.

• Native Chromium before the October 24 trunk merge: two actual Navigation dropdown imports in the post editor created distinct saved titles and identical link content through real REST requests. Both retained the existing stored draft / edited publish status behavior. The owned fixtures were deleted and original posts, post metadata, terms, relationships, comments, comment metadata and editor preferences were checked against the final run's snapshot.

The October 24 normal merge includes upstream #85390, which updates the Entity Fields/Actions compatibility layer for the Core API change in Core #14716. The Navigation implementation and its regression tests are unchanged. The same Site Editor crash also appears in the old trunk comparison baseline of a separate performance run; the template-switching E2E failure remains under investigation.

No Docker E2E or full repository test-suite result is claimed.

Maintainer action

Please apply [Type] Bug when reviewing this bug fix. Enforce labels requires exactly one [Type] label; the contributor account has read access and cannot apply it.

Use of AI Tools

OpenAI Codex selected and investigated the issue, authored the implementation and tests, ran automated validation and prepared this PR. A separate Codex agent reviewed the patch. The repository owner has not performed a human code review; maintainer review is still required.