fix: use the post type or taxonomy slug for settings section URLs

[wj-yuta-imai]

Context

The Settings page builds the deep links to each post type and taxonomy section (#/post-type/<route> and #/taxonomy/<route>) from the rewrite slug. The rewrite slug is not guaranteed to be unique — a custom post type or taxonomy can reuse a built-in type's rewrite slug — and it can change over time. As reported in #20864 (and the merged #20016 / #20341), this makes some sections unreachable: e.g. with Tutor LMS the Lessons, Quizzes and Assignments sections all resolve to the same URL, and with Directorist the taxonomy tags section opens the categories section. This PR builds the route from the unique, stable post type/taxonomy slug instead.

Note: for a content type whose rewrite slug differs from its name and which has no custom rest_base, the section URL changes. An old bookmark using the previous (rewrite-slug-based) URL will no longer match and the settings app falls back to its default section. This is the intended trade-off for stable, unique and always-reachable URLs.

Summary

This PR can be summarized in the following changelog entry:

• Fixes a bug where a Settings section could open the wrong content type when a custom post type or taxonomy reused a built-in type's rewrite slug.

Relevant technical choices:

• Route_Helper::get_route() now derives the route from the post type/taxonomy name, which is unique and stable, instead of the rewrite slug, which is neither. The leading-slash stripping and the rest_base handling are unchanged.
• The rest_base override is kept on purpose: a custom rest_base is required by the REST API to be unique, and when it is not set it defaults to the name, so it does not reintroduce the collision the rewrite slug caused. Happy to drop it as well if maintainers prefer the route to always be the name.
• The route value is only used to build the client-side Settings deep link (the packages/js settings router: /post-type/${route} and /taxonomy/${route}). It is not a REST route and not a storage key — the settings data is keyed by the post type/taxonomy name — so this change has no data-migration, front-end or SEO impact.
• The now-unused $rewrite parameter was removed from Route_Helper::get_route() and its three callers were updated (Settings_Integration post types and taxonomies, and the Set_Search_Appearance_Templates task link). Route_Helper is an internal helper, not a documented hook.
• Added unit tests for Route_Helper::get_route() (the class had none).
• I could not run composer test / composer check-branch-cs locally (full monorepo dependency install was unavailable in this environment). php -l passes on all changed files and the get_route() logic was verified against the four covered cases. CI will run the full suite.

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

• Install Yoast SEO and a plugin that registers post types whose rewrite slug collides with another type — for example Tutor LMS (Lessons, Quizzes, Assignments).
• Go to Yoast SEO > Settings and open the Content Types group in the menu.
• Click Lessons, then Quizzes, then Assignments in turn.
• Expected: each click opens that content type's own settings section (before this change they all opened the same section).
• The same can be checked for taxonomies with a plugin like Directorist (its tags vs. categories sections).

Relevant test scenarios

• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested with the browser console open
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• The Settings page deep links for post type and taxonomy sections.
• The "Set search appearance templates" task link (task list), which builds the same deep link.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.
• This PR also affects Yoast SEO for Google Docs. I have added a changelog entry starting with [yoast-doc-extension], added test instructions for Yoast SEO for Google Docs and attached the Google Docs Add-on label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities.
• During testing, I had activated all plugins that Yoast SEO provides integrations for.
• I have added unit tests to verify the code works as intended.
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.
• I have checked that the base branch is correctly set.
• I have run grunt build:images and committed the results, if my PR introduces or edits images or SVGs.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label.
• I have added my hours to the WBSO document.

Fixes #20864