Avoid light/dark mismatch between parts of the UI

@pdureau Your screenshots in #6 cover these cases, so I'm not uploading duplicates.

✅ Tested and works — applied MR !528, rebuilt caches and opened a page layout builder (Theme island disabled) and a Views builder (Theme island enabled, set to Dark) with Default Admin set to Light, Dark, and Auto (the latter under both OS color schemes): the builder always matched the admin UI. On Claro the Theme button is not rendered and the builder stays light. No light/dark mismatch left.

Gin Dark now gets a light builder and no Theme button, and the builder should not write the admin theme's state.

I suggest reading the computed color-scheme of the body instead, so it works on any theme. An explicit pick wins, otherwise the builder follows the page around it.

Also, already on 1.0.x: in Firefox, Shoelace dark reaches prefers-color-scheme inside our iframes, so a front theme following the system, like DSFR, can render dark there. color-scheme: normal on the Builder and Preview iframes stops it.

IMHO Gin contrib support is fine, as long as Default Admin is experimental; we drop it in a follow-up once it is stable.

I would still split the two jobs: Shoelace can follow any theme by reading the computed color-scheme of body, which also covers ui_suite themes through ui_skins and Claro, while the Theme button only switches Default Admin and Gin. I changed my mind when no pick, the builder should follow the page around it, not the browser: an admin theme set to Dark should stay dark in the builder, wdyt?

For DSFR: with a light OS and a dark builder, Firefox gives the iframe prefers-color-scheme: dark, inherited from .sl-theme-dark on the iframe element, so DSFR on "system" renders dark inside the Builder.
Chromium follows the OS, which is why it looks fine there.

Something else, I would keep the Theme island in the default profile once the mismatch is fixed.

With no pick the builder follows the page and writes nothing to the host, so an untouched button costs only a toolbar slot, and only on Default Admin and Gin.
A visible switch is what users expect, while an opt-in island in profile config is one editors never find.

Its tooltip should say it applies to the builder only, until #3606655: Allow user-configurable UI settings - starting with dark mode lets it drive the core setting.

Thanks, I pushed two fixes and put the island back in the default profile, since you are not against it for this ticket.
On Gin, the menu tested ginDarkMode, but Gin sets window.ginDarkmode.

With nothing picked, the menu also wrote the OS preference over the admin theme's Light or Dark, so builder pages could differ from the other admin pages: it now applies a stored pick only, and System restores the admin theme's mode.

Drupal itself now treats light and dark as basic: Default Admin ships Light, Dark and System, and #3606655: Allow user-configurable UI settings - starting with dark mode makes it a per-user setting.
Until that lands, the switch fills the gap for the builder only, and with no pick it keeps the admin theme's mode and writes nothing, so an untouched switch costs one toolbar slot.

For fewer islands in the shipped profiles before 1.0.0, I suggest a dedicated issue: list every island of the default profile, and judge each one on criteria we agree on first, such as discoverability, cost when unused, and what comparable tools ship.
Profiles already let a site remove any island, so the question is only the default, and I would like to settle it on those criteria rather than on preference, mine included.

Thanks, let's go.