A frontend boot failure is invisible: the app cannot report why nothing responds #618

The problem

If anything throws while static/js/main.js is wiring the UI, the app ends up in a state that looks alive but responds to nothing, and it cannot tell anyone why.

static/index.html loads two module scripts, main.js then ui-chrome.js. Inside main.js:

• lines 207-243 are a synchronous chain of fifteen wireX() calls
• the global error and unhandledrejection handlers are registered at lines 904-907, near the end of the module
• buildStripStems() bootstraps at 913

So a throw anywhere in that chain does two damaging things at once:

1. Every listener registered after the throw never attaches. That includes the delegated click handler at line 873 and the keydown handler at line 715.
2. The error handlers themselves never register, so nothing is logged anywhere.

What the user sees

Hover still works, because that is pure CSS. Text selection and typing still work, because those are native to the engine. Buttons do nothing and files cannot be dropped, because both need listeners that were never attached.

The result reads as a frozen app with no explanation.

Why the logs do not help

There is no earlier error capture anywhere in the frontend, and CSP script-src 'self' forbids an inline handler in the HTML, so none can be added there.

configure_logging() attaches the rotating file handler to the stemdeck logger only, so stemdeck.log never sees frontend problems at all. A failed module fetch would appear as a uvicorn access line in backend.log, but a JavaScript exception leaves no trace on the server side at all.

A reporter checking the obvious log finds nothing unusual, which is exactly what #617 describes.

Why this matters beyond one report

This is a class of failure, not a single bug. Any future throw in that chain produces the same silent, unreportable result, and the person hitting it has nothing to send. It also means a genuine environment problem, such as a JS file quarantined by antivirus or lost in a partial unzip, is indistinguishable from a StemDeck defect.

Constraints for anyone fixing it:

• Whatever captures the failure must not depend on main.js, since main.js is what failed.
• It must have no imports of its own, or it can fail for the same reason it exists to report.
• It cannot use inline script, because of CSP.
• It has to be visible in the app, because a desktop user cannot easily open devtools in the Tauri shell.

Found while investigating #617.