Give gadget UIs the Workshop's theme, as gatekeeper apps already have

[hx-natthawat]

Gatekeeper apps receive the Workshop's appearance explicitly — GatekeeperAppThemeReceiver.setTheme({ mode, accentColor }) in workshop-shared/src/theme.ts, pushed from SandboxedGatekeeperApp.tsx on every change. Gadget UIs do not. Their iframe (GadgetUI.tsx) is handed a MessagePort, a console relay and an Escape relay, and nothing about the theme.

That matters because the theme cannot be inferred from inside the frame. Measured in headless Chrome with a page that sets color-scheme on <html> the way theme.ts does, embedding an iframe with GadgetUI's sandbox attributes that reports matchMedia('(prefers-color-scheme: dark)').matches:

parent color-scheme	iframe prefers-color-scheme: dark
dark	false
light	false

A sandboxed frame follows the OS, not the embedder. So a gadget or a format blueprint that wants a dark variant today has two bad choices: follow the OS and contradict the Workshop's toggle, or stay light.

Proposal

Extend the existing handshake rather than add a channel:

1. In GadgetUI.tsx, once the handshake port arrives, post { type: 'theme', mode, accentColor } into the frame (iframe.contentWindow.postMessage), and again whenever resolvedThemeMode / accent change — the same trigger SandboxedGatekeeperApp already uses.
2. In the injected prefix, receive it: set document.documentElement.style.colorScheme = mode so UA widgets and light-dark() follow, keep the latest value somewhere gadget code can read synchronously (e.g. globalThis.workshopTheme), and dispatch a workshoptheme event on window so a gadget can re-render on change.
3. Type it as the existing GatekeeperAppTheme — same shape, same semantics; nothing new to learn.

Two small hunks in one file plus a type re-use. Gadgets that ignore it see no change; the bundled format blueprints (workspace-slides first) can then carry a dark chrome that agrees with the app around them.

Happy to open the PR if this is wanted; asking first per CONTRIBUTING.