The full IDE has offered a light theme under Einstellungen all along,
but the embedded starter only ever constructed a ThemeManager and never
asked it for a theme, so an embedded IDE came up in whatever the CSS
defaults happened to be - a dark rectangle in the middle of a light
page, and no way to ask for anything else.

A `'theme': 'light'` in data-sql-online now chooses it, defaulting to
"dark" as before, and the ThemeManager is built in MainEmbedded: after
readConfig, which knows the theme, and before initGUI, so nothing is
painted in the wrong colours first.

Editor passed a hardcoded "myCustomThemeDark" to monaco.editor.create,
which applies the theme to every editor on the page, not just the one
being created. An editor built after the switch therefore dragged them
all back to dark - light surroundings around a dark editor. It now takes
the name from ThemeManager, which records what the last switch chose.

Every icon whose class carries "-dark" is a light glyph drawn for a dark
panel. The plain ones are #c5c5c5, which against the light theme's white
is barely a smudge, and there are no light-theme counterparts to switch
to - so they are darkened instead, through a filter the theme hands down
as a custom property. Saturation is put back as they darken, so the
coloured ones stay themselves. img_open-file joins them: it is a #c5c5c5
glyph too and only misses the suffix.

The states need spelling out, because .jo_button sets `filter` itself
and a filter replaces rather than adds: without this an icon snapped
back to its unreadable grey under the pointer, and the buttons that are
disabled kept the plain grayscale() they are greyed with and never
darkened at all. The rules here are more specific than the button ones,
so they win however the files are ordered.

The dark theme's filter is brightness(1) rather than `none`: `none` may
not appear beside other functions, so `none grayscale()` is invalid and
the whole declaration would be dropped.

Everything needed to ship this fork's embedded build as a hyperbook
element, kept apart from the IDE changes so that rebasing onto upstream
stays cheap:

- a release workflow that builds the embedded bundle and attaches it to
  a GitHub release
- includeIDE.js points at onlineide2.openpatch.org rather than
  learnj.de
- EmbeddedIndexedDB stores scripts and databases through hyperbook's own
  Dexie database instead of opening an IndexedDB of its own, so a
  reader's work lives with the rest of the book's state
- package-lock.json is tracked (upstream ignores it) so the release
  workflow installs the exact tree that was tested

The tables are reached as `hyperbook.store.db.sqlideScripts` and
`.sqlideDatabases`. `hyperbook.store` itself only carries db, export,
reset and import, so the tables were undefined one level up: open() took
the "not available" branch, never called back, and nothing was ever
loaded or saved.

A hyperbook carries a <dark-mode-toggle> its reader can flip, and an IDE
embedded in the page should be in the same colours as the text around it
rather than a dark rectangle in a light page.

With no `theme` in the config, the theme now comes from that element -
its `mode` property, falling back to the attribute for the moment before
the custom element has been upgraded - and follows it live through the
component's `colorschemechange` event, so flipping the toggle re-themes
the IDE without a reload. It re-reads once whenDefined() resolves as
well, so a toggle whose script loads after the IDE still gets honoured.

An explicitly configured theme still wins, and a page with no toggle
says nothing about its colours, so the IDE stays dark there.

ci: publish immutable embedded releases to Cloudflare R2