ci: make the self-hosted E2E lanes merge-blocking

[rominf]

Depends on #280 — must land after it. Draft until then: this branch is cut
from main, so its own Windows lane still hits the EAI-8031 failure that #280
declares as a known bug, and with continue-on-error gone that now reads red.
I'll rebase and mark ready once #280 merges.

• If this PR fixes a bug, searched tests/e2e-cucumber/expectations.toml for the fixed ticket ID and removed/narrowed any now-stale xfail rows. — n/a, no product change.

Summary

The workflow header contradicted itself, and both halves were wrong in
opposite directions. It said the lanes were non-blocking (continue-on-error)
and that their check names were already in main's required-status-check
list. In fact none of the five self-hosted checks are required today, so a
reader had no way to tell what actually gates a merge.

This resolves the contradiction in the direction the lanes are now good for,
and drops continue-on-error from the four lane jobs.

Why now: every self-hosted lane has been green except Strix Halo Windows,
whose only host-independent failure is declared as a known bug in #280. A lane
that is permanently red and advisory trains everyone to ignore it, which
gives the same coverage as having no Windows GPU lane at all.

One correction the header now records, because it is easy to get backwards:
continue-on-error was never what kept these lanes out of the merge gate. It
suppresses only the workflow conclusion — the per-job check run still reports
failure (verified on 1807a6cd, where the run is success while
E2E tests (Strix Halo, Windows) is failure). Removing it just stops a run
summary reading green over a red lane.

And one consequence it now warns about: a required self-hosted check turns a
downed runner into a merge outage — the job stays queued, its check never
reports, and branch protection waits forever. That is the #138 failure mode, and
it is why these lanes already live in their own concurrency group. There is no
in-workflow escape hatch; the answer is to restore the runner or temporarily
drop its check from the required list.

Risk: medium — this is what makes four GPU lanes able to block merges. The
branch-protection half lives outside the repo, so this file is the only place a
reader can learn the lanes are blocking.

Scope boundary

Comment and continue-on-error changes only. No job logic, no runs-on, no
if: conditions, no step changes — the lanes run exactly as before.

Test plan

• prek run --files .github/workflows/e2e-selfhosted.yml — clean (check yaml
  passes).
• Job list unchanged after the edit: changes, e2e-gpu,
  e2e-gpu-strix-ubuntu, e2e-gpu-strix-windows, e2e-wsl, e2e-report.
• The PR's own run is the real check: with continue-on-error gone, the five
  self-hosted checks must all report green once rebased onto a main that
  contains test(e2e): xfail the Windows HF-checkpoint serve (EAI-8031) #280.