ci(forge-e2e): dispatch through Dispatron, keep the reporting here

[zoroyihan7]

What

The same split as #1489, applied to the check that was copy-pasted from the same script: submit, poll, translate and cancel move behind dispatron-ci; the commit status and the sticky comment stay here.

DO NOT MERGE yet — it depends on Dispatron changes that are not deployed, and on GPU capacity that the cluster does not currently have.

Why

Dispatch is the same for every repository that wants a GPU check, and it was duplicated per check as well as per repository — this script and ci-e2e-dispatch.sh share post_status, report_upsert, gh_status_on, summary and cleanup verbatim. How this repository annotates its own pull requests is nobody else's business and stays.

What this loses

The performance rows. fetch_forge_result read the run's stdout back through the retired backend's log-search route (GET /workloads/{uid}/logs?keywords=__FORGE_RESULT__) and Dispatron has no such route. The renderer already guards that whole block on having a result, so the comment omits baseline, best, speedup, validation and iterations.

It is a real loss and a small one, and the evidence is worth recording:

• the fetch runs on the Succeeded branch only;
• of the last 100 workflow runs, 33 skipped the GPU job on the path gate and all 16 that reached it failed — so no success, so no fetch;
• further back, in a window where the job was passing, a green run's job log carries no __FORGE_RESULT__ at all;
• the sticky comments on both PRs that had a success now show a later timeout, with no performance rows and no reactions.

So the numbers have been absent for some time and nobody has said so. Restoring them needs a result channel on the run record rather than a log scrape; Dispatron's TODO.md carries that question.

What this does not lose

The timeline. The renderer reads queue→dispatch / run time / total out of detail.orchestration.conditions[]. The same three instants come back on the CLI's terminal event, so they are put back into the shape it already reads rather than changing forge_e2e_report.py. Without that wrapper all three would render as –.

Also gone

E2E_INFRA_TYPE and its kubernetes-only check, with the endpoint that honoured them. Which infrastructure a run lands on is Dispatron's platform row to decide, not the caller's to assert.

Tested

Driver exercised against a stub CLI over every outcome:

case	exit	reported as
succeeded	0	✅ PASS
failed (multi-line platform error)	1	❌ FAIL, error rendered with <br>
cancelled	1	🚫 CANCELLED — deliberately not a "look for a bug" red
timeout	1	❌ FAIL (timeout)
CLI died before dispatching	1	❌ never dispatched — distinct from a run that failed

The rendered comment was checked with a stubbed curl, including the restored timeline rows.

Depends on

Dispatron: a Claw task-DAG launcher, a kernelforge spec builder that carries the run script, a task-backed evidence source, and CLI flags --kind / --image / --pull-ref. All committed on feat/facade-hyperloom-spec, none deployed.

Blast radius

None while unmerged. A workflow reaches a run through the PR's own merge ref, so every other PR keeps main's script and the incumbent backend.