Separate the Page Type axis from feature grouping in the admin

### Description

WP SEO organizes information along two different axes, and they should not be conflated:

- **Feature Category** -- how features are grouped on the read-only WP SEO Features screen ("Technical SEO", "Social sharing"). Display-only; see `docs/adr/0009-categories-group-features-for-display-only.md`. Answers *"do I want this behavior at all?"*
- **Page Type** -- the kind of page whose SEO output is being configured: home page, single post, post type archive, term archive, author archive, date archive, search results, 404. Answers *"what should the title format be **here**?"*

These are orthogonal. A site enables the `titles` feature once, then configures title formats per Page Type.

Today the Page Type axis exists only as inline sections stacked on a single long settings page (`Settings -> SEO`, registered in `php/class-wp-seo-settings.php`): Home Page, Post Types, Single {Post Type} Defaults, {Post Type} Archives, {Taxonomy} Archives, Author Archives, Date Archives, Search Results, 404 Page. There is no navigation between them.

This issue covers separating that axis out properly -- most likely as sibling pages under the new top-level WP SEO menu, navigable rather than stacked, so that configuring one Page Type does not mean scrolling past all the others.

Depends on #194 (moving the existing settings page under the WP SEO menu) and is informed by #195 (the feature taxonomy), but is a distinct piece of work from either.

### Use Case

Keep "which features are on" and "how each page type is configured" as separate, navigable concerns rather than one long page plus one flat list. As features and supported page types grow, a single stacked settings page becomes progressively harder to use.

Note: "Page Type" is the agreed term for this axis. "Context" was considered and rejected -- it collides with `Uses_Context` in wp-type-extensions, Gutenberg block context, and the REST API `context` parameter.