Remove the inert cross-runtime E2E foundation

[jyaunches]

Objective

Remove the unused cross-runtime E2E model instead of retaining it as an implied future product surface.

Scope

• Delete execution-profile, scenario, runtime-matrix, and parity-evidence modules.
• Delete the unused runtime-provider fixture, foundation fixtures, and coupled support tests.
• Remove runtimeCase plumbing from the target registry and run plan.
• Remove unused execution-evidence types and methods.
• Remove the corresponding E2E documentation section.

Evidence

test/e2e/docs/README.md calls this an inert foundation. No canonical target, workflow selector, live scenario, or production registration consumes it.

Expected net reduction: 2,500–2,650 LOC.

Acceptance criteria

• No cross-runtime foundation reference remains.
• Executable target planning is unchanged.
• Artifact redaction outside the unused evidence type is unchanged.
• Documentation describes only current E2E architecture.

Validation

Run the E2E-support project, project-membership check, repository checks, and docs build.

Decision

A maintainer must confirm that this unconsumed product direction should be removed before implementation.

[wscurran]

✨ Thanks for the cleanup proposal. The scope and acceptance criteria are clear. This will reduce test infrastructure complexity.

[VishnuR23]

Requesting the decision this issue gates on, so it can move.

The Decision section says a maintainer must confirm that the unconsumed cross-runtime direction should be removed before implementation. @wscurran commented that the scope and acceptance criteria are clear and that the change would reduce test infrastructure complexity, which reads as support for the proposal rather than the explicit removal decision the section asks for.

I would like to implement this, and I do not want to start a 2,500-line deletion against an unconfirmed product direction. Could a maintainer confirm one of the following?

1. The cross-runtime foundation is not accepted near-term product scope and can be removed.
2. It should stay, and this issue closes.

Two notes from reading the code, offered as evidence rather than as a decision:

• test/e2e/docs/README.md describes the foundation as inert, and I found no canonical target, workflow selector, live scenario, or production registration that consumes it.
• Make the typed E2E registry executable-only #8286 states that the cross-runtime decision must complete first, so this issue currently blocks that one as well.

If the answer is to remove, I will follow the stated scope and validation, and split it if the diff is easier to review in parts. I checked open pull requests and found none touching this work.

[cv]

The audit supports the execution-inert claim, with one scope correction.

At main commit 9b79f3e4, the listed foundation is 2,504 lines. No canonical live target calls .runtimeCase(...); only the synthetic support test does. compileRuntimeMatrix, executeRuntimeCaseThroughProvider, writeExecutionEvidence, and the cross-runtime fixture are otherwise exercised only by their own tests. The live registry calls buildLiveTargetRunPlan(target) without a runtime matrix.

Preserve or relocate the 51-line compatibility contract before deletion. It protects the live matrix, workflow plan, and risk-plan fingerprints. The generic artifact sink also still needs its redaction coverage, even if the foundation-specific evidence writer is removed. That leaves about 2,453 lines in the closed island, subject to the final diff.

There is also an active overlap: #8062 and #8079 import execution-profile.ts and scenario.ts. Do not merge a deletion that merely breaks those PRs, and do not retain this foundation only to support another dormant model. The clean sequence is:

1. Record in [Epic] Support native Podman with buildless managed onboarding #7744 that the trusted GitHub Actions workflow owns the qualification matrix and evidence aggregation.
2. Rework or close the standalone compiler PRs against that decision.
3. Delete the closed foundation while retaining the small live compatibility and redaction contracts.

With that ownership decision, this issue is ready for implementation.