chore(deps): upgrade monaco-editor to 0.56.0

[huhamhire]

Breaking change to adapt to

0.56.0 replaces the identity exports map with a rewriting one:

// 0.55.1                    // 0.56.0
"./*": "./*"                 "./*.js": "./esm/vs/*.js",
                             "./*":    "./esm/vs/*.js"

So every deep import that still spelled the prefix now resolves to esm/vs/esm/vs/… — the build fails outright rather than degrading, which at least makes it loud.

0.56.0 also moved the worker-backed language services from vs/language/<x>/monaco.contribution.js to typed namespaces on the package entry. That lets this get simpler rather than merely adapted: the four *Defaults we disable are now read straight off monaco, with real types. Gone with it — a hand-written LangServiceDefaults interface, a cast through unknown (the old .d.ts was an empty export {}), and a by-name lookup that existed only to survive that untyped access.

// before                                        // after
...defaultsOf(tsLang, ['typescriptDefaults',     monaco.typescript.typescriptDefaults,
                       'javascriptDefaults']),   monaco.typescript.javascriptDefaults,

Legacy editor issues — re-checked, not assumed

Both suppressed Monaco errors are still present in 0.56.0, so the suppression stays:

Error	0.56.0	Raised as
Missing requestHandler or method:	still there	plain Promise.reject in editorWebWorker.$fmr → unhandledrejection
TextModel got disposed before DiffEditorWidget model got reset	still there	onUnexpectedError(new BugIndicatingError(...)) in diffEditorWidget → window error

Both still surface through exactly the two listeners we have, so neither the suppression nor its shape needed changing. The finding is recorded in the source comment, so the next upgrade re-checks rather than assuming — a suppression that outlives its cause silently swallows a message that has become meaningful again.

Security: #208 shrinks substantially, but does not close

Monaco''s pinned dompurify moves 3.2.7 → 3.4.8, so the vulnerable 3.2.7 copy is gone and the 16 alerts tracked in #208 collapse to 4.

It does not close, and the issue''s own close condition turned out to be the wrong bar: newer advisories widened the affected range past 3.4.11, so even mermaid''s copy is in scope now. Three of the four need dompurify ≥ 3.4.12 (another monaco release); the fourth (GHSA-55q2-fjhq-7xh7) has no fix in any published version. #208 is updated with the revised bar rather than left stale.

Note: npm audit proposes "fixing" this by moving monaco to 0.53.0 — a downgrade to an older, more vulnerable copy. Not taken. Per repo policy no overrides either.

Verification

lint / typecheck / test / build all pass — and the build is a meaningful signal here, since the breaking change manifests as a module-resolution failure.

Not verified in the running app. Worth a look before merging, as these are the parts a resolution/API change would hit while still building: the diff renders with syntax coloring, switching files quickly does not spam the console (the suppression still catching what it should), and the inline code context in a comment still loads.