Migrate Delete Route journey to GOV.UK Questions

[gunndabad]

Context

Continues the move off WebCommon.FormFlow onto GovUk.Questions.AspNetCore (DFE issue #369).
This one is Delete Route to professional status.

Delete Route is the simplest of the three route journeys — a linear walk of Index → Reason →
Check answers — so it follows Add Route (#3685) rather than the hub-and-spoke path model Edit
Route (#3691) needed. Nothing here is novel; it's worth reading mainly for the two things I
deleted rather than ported.

Based on main, not on #3691. The only file the two branches share is
EditRoute/PermissionsTests, which covers both journeys — see below.

Changes proposed in this pull request

DeleteRouteJourneyCoordinator holds what the pages shared — the page caption, the person
id, and CancelAsync (delete the uploaded evidence file, drop the instance, return to the
record). DeleteRouteState loses IRegisterJourney, its Initialized flag and its
IsComplete computed property, and is now plain data.

Index is [StartsJourney] and advances to Reason with SetAsFirstStep, so Reason is step 0
— its back link is null and falls back to the person's qualifications — and the redirect page
doesn't stay in the path.

The check answers completeness guard is gone. Unlike Edit Route, where the detail page is a
hub and the user can go straight to check answers at any point, here the page is reachable only
by posting the reason page, which path validation already enforces. Same reasoning as Add Route,
and the opposite conclusion to Edit Route — worth being explicit about, since the three journeys
now differ on this.

Cancel is a form field, not a handler. Both /cancel handler routes are gone, and with them
the {handler?} segments from the two page routes: the library validates the request URL against
the journey path, so a distinct path or query is an invalid step and redirects forever. The
buttons now POST to the same URL with name="Cancel" value="true".

Change links use the library's returnUrl in place of the fromCheckAnswers flag, so
DeleteRouteLinkGenerator drops qualificationId from its arguments — scoping route values come
from InstanceId.RouteValues — and CheckAnswers loads its reference data in
OnPageHandlerExecutionAsync rather than a separate OnGetAsync.

CheckRouteToProfessionalStatusExistsFilterFactory moves from per-page attributes into the
folder's Conventions, matching Edit Route.

Guidance to review

I did not take #3691's IOrderedFilter/-200 change to
CheckRouteToProfessionalStatusExistsFilter. That change exists so Edit Route's coordinator can
seed its state from the route before the journey filter runs. Delete Route's state is just the
reason, so GetStartingState() needs nothing from the request, and the filter running at its
default order is fine. Leaving the shared file alone keeps these two branches from touching it —
whichever lands second, that file merges cleanly.

EditRoute/PermissionsTests will conflict with #3691. It's a single file covering both
journeys' pages, and both branches change how the delete journey is seeded in it. The conflict is
confined to one switch expression; I've kept the change as small as it can be. Whichever merges
second takes the other's Edit Route arm and keeps its own Delete Route arm.

Test content. The two page test classes move onto a new DeleteRouteTestBase that seeds the
path via JourneyHelper; cancel tests POST Cancel=true instead of following a formaction; and
journey-deletion assertions read IJourneyStateStorage rather than JourneyInstance.Completed,
since the library has no notion of completing an instance. I added back link coverage for both
pages, which nothing asserted before.

Verified locally:

Suite	Result
SupportUi.Tests	3880 passed, 3 skipped
SupportUi.Tests, RoutesToProfessionalStatus	597 passed, 2 skipped
SupportUi.EndToEndTests, RoutesToProfessionalStatus	26 passed

Two flakes worth naming, neither in Delete Route. One E2E run failed
EditRouteToProfessionalStatusTests.EditEachField_Cya_ShowsEditedContent on a training provider
name — it passes in isolation and on re-run, and looks like the usual committed-test-data
interaction. One full SupportUi.Tests run reported a single failure whose name I didn't capture
before two subsequent clean full runs.

No emitted events change, so docs/process-type-events.md is untouched.

Checklist

• Attach to Trello card
• Rebased master
• Cleaned commit history
• Tested by running locally