fix: harden startup and keybinding paths against errors seen in alpha.38

[dubadub]

Fixes the five real issues Sentry reported against 0.1.0-alpha.38 in the first hours of telemetry from real users. All were unhandled errors, none crashed the app.

Issue	Error	Events
EDITOR-2	TypeError: Object has been destroyed	3
EDITOR-3	A resource provider for 'user-storage:/user/toolbar.json' is not registered	2
EDITOR-4 / EDITOR-6	Cannot read properties of undefined (reading 'keyCode')	2
EDITOR-5	Cannot get key code from the keyboard event	1

Splash screen — EDITOR-2

The maxDuration timer outlives the windows it closes. Quitting during startup destroys both windows, and splashScreenWindow.close() then throws. Guarded with isDestroyed() — including mainWindow.isVisible() on the same path, which fails the same way; the reported frame was just whichever ran first.

Monaco keybinding dispatch — EDITOR-4 / EDITOR-6

KeyCode.createKeyCode deliberately leaves key unset for modifier-only chords, so the keyCode.key! assertion in toKeybinding is not sound. It now returns undefined and getDispatchChords emits null, which its (string | null)[] signature already allows — the same handling getSingleModifierDispatchPart directly above it already applies to this case.

Keybinding registry — EDITOR-5

Some layouts and IMEs deliver events with no usable code, keyCode or keyIdentifier. KeyCode.createKeyCode throws on those, and KebindingRegistry.run is called straight from a keydown listener, so the error escapes unhandled. No keybinding can match such an event, so it is dropped. Both EDITOR-5 and EDITOR-4/6 came from one user in France on Windows 10 within the same second — likely one keypress hitting two listeners.

Toolbar storage — EDITOR-3

@postConstruct init() left doInit() floating, so a failure to resolve the config surfaced as an unhandled rejection; it is now handled (the toolbar already falls back to its defaults).

DefaultResourceProvider.get also swallowed every resolver error before reporting that nothing handled the URI — which is why the Sentry report says nothing about the underlying cause. They are now attached as the error's cause.

This is the part I am least confident about. The catch makes the symptom benign and the next occurrence diagnosable, but it does not fix why the user-storage: provider was unavailable at that moment. That needs the cause data this PR adds.

Verification

• lerna run compile passes for @theia/core, @theia/monaco, @theia/toolbar; eslint clean on all touched files.
• Both root causes confirmed empirically against the compiled code — a modifier-only event yields key === undefined, and an event with no usable code/keyCode throws out of createKeyCode.
• Added a regression test in keybinding.spec.ts for the unmappable-event case.

⚠️ The test suite was not run. This machine has Node 20.11.1 and the repo requires ≥ 22, so mocha refuses to start. The new test is type-checked and compiles but has never executed — please confirm CI is green before merging.

The splash-screen and toolbar fixes are defensive guards validated by inspection; neither race was reproduced locally.