CMS - E2E fixtures: seed dedicated test pages instead of depending on editable sample content

[dfe-lance]

Nine E2E tests failed against any database whose sample content had been edited. Two
symptoms, one cause: the tests asserted on content editors are free to change.

Seven BackToTopTests navigated to /wiki/wiki-sandbox and /guidance/short-page and
never got past their first assertion — both page rows existed with zero PageNodeVersions,
so the app returned 404. Two admin analytics tests searched for widget and asserted the
prior-search panel lists hit links; whether that matched anything was a matter of luck, and
the luck ran out.

The sample seeder cannot repair the first case. It imports with ContentImportMode.Skip,
and the collision test is the page identity rather than whether the page has anything to
render, so an emptied page is walked past on every run and the route stays 404 for good.
Skip is correct there — the seed button must never overwrite an editor's work — it just
cannot be the recovery mechanism.

What changed

A second content-staging bundle, a second seeder, and a pinned /development-testing root
that nothing else creates:

Fixture	Type	In search	Purpose
long-page	wiki	no	The half of the back-to-top contract that scrolls
short-page	content	no	Fits the viewport; the link must never reveal
search-fixture	content	yes	Carries the keyword testfixture so a search is guaranteed a hit

• Imported with Replace, which is what brings an emptied fixture back. Nothing under that
  root is anyone's work, so a fixture is always in the state the tests expect rather than
  whatever the last person to open it left behind.
• The root is a folder and is hidden from the menu, so an ordinary visitor has no route to
  it, while an editor browsing the page tree sees one plainly-labelled container instead of
  test pages interleaved with their own.
• Seeded behind the existing Seed sample CMS pages button — the pages are useful to
  develop against, not only to test against — and at start-up wherever SeedDevelopmentData
  is set, so the review app the suite runs against always has them. Never in Production.
• Runtime-created E2E fixture … pages move under the same root. Teardown there is
  best-effort and the delete route is a soft delete, so a leaked page stays in the tree and
  travels to the next environment inside a content export — eighteen are in a preproduction
  bundle already. They now leak somewhere nobody has to ask what they are. Their seeding
  helper was duplicated verbatim across two test classes; it moves to CmsSeedHelpers.

wiki-sandbox and short-page are removed from the sample bundle. The rows are left where
they are on environments that already have them — no longer seeded, and an editor can delete
them.

Acceptance criteria

• A development-testing root exists only where it has been seeded, and appears in
  neither the site navigation nor search results
• Re-running the seed repairs a fixture page whose versions have been deleted
• BackToTopTests target fixture pages and pass against a database whose sample content
  has been edited
• The two analytics tests no longer depend on widget matching the corpus
• Seeding is unavailable in production
• The full E2E suite runs green locally

One deliberate deviation: the search-fixture page is visible to search. The two analytics
tests assert that fixture content appears in search results, so suppressing it would suppress
the thing under test. The root and the other two fixtures are excluded.

Testing

• Unit: 5256 passed, 0 failed
• Integration: 811 passed; the single failure is
  SearchTelemetryE2ETests.SearchAsync_WidenedQuery_P95LatencyBelow300ms, which fails on
  unmodified main and is excluded by the CI filter
• E2E (Category!=VisualRegression): 206 passed, 0 failed, 4 skipped
• Full Release build of the solution: clean, no new warnings

Written test-first. The repair guarantee and the production gate were each verified to fail
when the corresponding code is removed.

Not in scope

The 18 stray E2E fixture … pages already in a preproduction bundle are not swept up.
PageNodeService.DeleteAsync only soft-deletes, so removing them needs a genuine purge —
worth a follow-up alongside a sweeper for the cancelled-run case. New strays now land under
the fixture root rather than /help.

Closes #443
Closes #412
AB#303114

[github-actions]

Review app for PR 447 was deleted