test(e2e): retire Hermes GPU fallback wrapper before ForwardTcp restore

## Outcome

The Hermes GPU fallback E2E completes its compatibility create with the real OpenShell executable identity. Installer recovery then authenticates and reuses the existing ForwardTcp listeners on ports 18789 and 8642.

## Reproduction

1. Run the `Hermes GPU startup (fallback, docker)` target.
2. The E2E-only wrapper rejects the native `--gpu` create before progress.
3. The compatibility create succeeds and starts ForwardTcp listeners.
4. Installer post-check recovery reports both ports as occupied and exits 1.

Observed on full-main run 34254574948, job 102159457888, candidate `d10ba0e23d6b867aa0c23874f87263d5ada4ddfc`. The same signature reproduced on PR run 34271175831, job 102213808446.

## Root cause

The fault-injection wrapper delegates the compatibility route and every later command with `exec` into the real OpenShell binary. Direct ForwardTcp ownership checks compare the configured executable with the live process executable. The listener is therefore healthy but cannot be authenticated as the wrapper target, and recovery fails closed instead of adopting it.

## Acceptance criteria

- The fixture still rejects only the native `--gpu` create before progress.
- The fixture restores the real OpenShell executable identity before the compatibility create launches host forwards.
- Fixed-label fallback evidence remains secret-free and records the same three route events.
- Foreign, ambiguous, or changing listeners remain rejected by production ownership checks.
- The focused E2E-support regression passes.
- `Hermes GPU startup (fallback, docker)` passes on the fixing PR commit.

## Scope boundary

Do not relax production ForwardTcp ownership checks. Do not adopt or terminate an unproved listener. Do not change managed images or GPU route behavior.

Part of #10979.