[Feature]: Report a failure to GitHub from the notification centre #374

Problem

When something fails, the user gets a transient #error banner and the
traceback goes to a log file they will never open. Dismiss the banner, or
reload, and the failure is gone: nothing records that it happened, and nothing
helps the user tell us about it.

#359 made the case already:

This is the difference between a bug report we can act on and one we cannot.
#343 took a screenshot, a reading of the transport clock, and a walk through
the engine source to get to a hypothesis, and it still is not confirmed.

#343 is the standing proof — its author guessed at a GPU cause and sent the
investigation the wrong way, because the app gave them nothing to paste.

Meanwhile the backend has written good evidence on every pipeline failure since
#277 — jobs/failed/<id>/error.txt carries the classified cause, device,
model, stage timings and a 40-line stderr tail — and no API ever served it.
The UI only ever had the one-line error_detail.

What it should do

Failures should land somewhere durable, and turning one into a bug report
should be one click:

• A notification card that survives a reload, for import, playback, export and
  update failures.
• Opening it shows what failed and the technical detail before anything is
  sent.
• A "Report on GitHub" button that opens the bug form pre-filled with version,
  OS, install method, stage, device, model and the stderr tail.

The user still writes what they were doing and ticks the preflight boxes —
GitHub cannot prefill checkboxes, and "I searched for duplicates" should stay a
promise the reporter makes.

Constraint

Issues are public. The report must carry technical details only — no track
title, no source URL. The user can add either if it helps.