[3.x] Support pages with more output file extensions (Sitemap inclusion policy)

[emmadesilva]

What changed:

• HydePage::showInSitemap() (packages/framework/src/Pages/Concerns/HydePage.php:412) reads the sitemap front matter key, defaulting to whether the resolved output path ends in .html — honoring the D3 constraint to use getOutputPath() rather than the static outputExtension(), so an InMemoryPage('robots.txt') self-excludes despite statically reporting .html. Front matter wins both ways, so sitemap: true can opt a non-HTML page in.
• SitemapGenerator::generate() now filters on showInSitemap() instead of instanceof Redirect, fixing the production search.json leak.
• Redirect overrides the method to return false unconditionally, mirroring its showInNavigation(). This is a small refinement of D3's "defaults false for redirects" (no front-matter opt-in), which I recorded in the epic — it matches the existing release note that redirect routes are intrinsically excluded, and redirects in sitemaps are an SEO anti-pattern anyway.

Tests: testShowInSitemap joined the BaseHydePageUnitTest contract and all six page unit tests. Two existing tests asserted the leak as expected behavior and were flipped: SitemapServiceTest now asserts the docs search page stays while the search index is excluded, and SitemapFeatureTest's expected XML dropped its docs/search.json entry and gained a sitemap: false page exercised through the real build:sitemap command. NonHtmlPageOutputTest got an end-to-end guard: a registered robots.txt page built by the real build command is asserted absent from the built sitemap — the exact regression the D3 note warns about.

Docs: Release notes in HYDEPHP_V3_PLANNING.md cover the new feature and the bugfix; the epic's D3 and PR 4 sections are marked ✅ Implemented with notes. No UPGRADE.md entry — the fix requires no user action, and nothing realistic depended on search indexes appearing in sitemaps.