[Feature] [Steam CEF Toolkit] Add CSSLoader-compatible theme loading primitives

[NightHammer1000]

The toolkit should be able to load CSSLoader-compatible themes into Steam CEF, as a reusable primitive.

This issue is only the Steam and CEF layer. The Theme Browser, Manager and Installer are a WSGM feature, tracked in #44.

Not part of the 2.0 milestone.

What the toolkit provides

Load and inject CSSLoader-compatible themes, unload them cleanly, support multiple enabled themes where CSSLoader semantics allow, keep theme order and priority, reapply after CEF recreation, hot reload or reconnect, never inject twice, expose theme metadata, enabled state and configuration schema to consumers, and restore Steam's original styling on teardown.

Compatibility

Use the CSSLoader project as the behavioural and package-format reference, covering its package layout, manifests, user-configurable variables, dependencies and shared assets, ordering rules, enable and disable semantics, and version metadata where consumers need it.

Do not invent a WSGM-only theme format unless there is no alternative. Existing CSSLoader themes should work with little or no modification.

Boundaries

The toolkit stays feature-agnostic: loading, lifecycle and configuration primitives only. No theme browser, no repository or store UI, no installer, no updater, no management UX.

The WSGM feature in #44 consumes this, plus custom right-QAM tabs (#42) and custom pages (#24).

Done when

Existing CSSLoader themes load and unload through the toolkit, the metadata WSGM needs is exposed through a stable API, theme state survives CEF reload and reconnect, teardown restores an unmodified Steam UI, and no WSGM-specific browser UX lives in the toolkit.

[NightHammer1000]

Read SDH-CssLoader at b1bc683. No code copied. It turns out to use the same architecture the toolkit already has.

CSSLoader does not do its work from inside the page. Its Python half (css_browserhook.py) opens the same door we do: http://127.0.0.1:8080/json/version to find the client, a CDP websocket per tab, Runtime.evaluate to create a <style> element and append it to document.head, then a read-back check (has_element), because an evaluate returning success is not proof the style survived.

That is our transport, patch-verify discipline and per-target model, arrived at independently. So this is not a new mechanism, it is a new surface on the one we have, and PersistentSteamUiTransport already handles the parts CSSLoader hand-rolls: generation tracking, reconnection, one connection per target role.

Worth copying in approach:

• Injects are identified and transactional. Each block carries a uuid, and adds and removes are batched into one commit instead of one evaluate at a time. A theme is many blocks, and applying them individually is how you get a half-applied theme.
• Re-injection after a client reload is normal, not exceptional. CSSLoader has a force_reinject path because styles die with the document. We already model that as a document generation change, so the equivalent is a patch that reapplies on generation advance rather than a timer.
• Every Steam window is its own target. CSSLoader enumerates tabs by name and injects into each. A theme that only styles SharedJSContext leaves the popups unstyled.

The part that does not transfer: CSSLoader's class-name mapping (initialize_class_mappings) exists because Steam's class names are content hashes that change every client build, while themes are authored against readable names. That is the real cost of CSSLoader compatibility, and it is not a transport problem. It is a mapping table someone has to keep current, and it is the thing most likely to make this feature look broken after a Steam update. Worth deciding deliberately whether to take that on before building the loader, because the loader itself is the easy half.

Also relevant to #44: a theme browser is a registered page, so it sits behind #24.