rml-compositing: make the window field actually render (2 real bugs)

Diagnosed live (nested unbox + grim screenshots). Two bugs stopped any window
from showing; both fixed and visually confirmed (multi-window, live-updating,
focus highlight, RCSS tiling).

1. kernel (ui_substrate.cpp, adopt_node) — STABLE TEXTURE ID across re-imports.
   The live import did glDeleteTextures+glGenTextures every commit, minting a NEW
   GL id each frame. But RmlUi's image()/<img> decorator caches the texture HANDLE
   it gets from LoadTexture(uri) ONCE, so after the first re-import it drew a
   DELETED texture -> blank. Now node.tex is allocated ONCE and just re-pointed at
   the new EGLImage (dmabuf) / re-uploaded (shm) on each re-import, destroying the
   previous EGLImage after the rebind. The id stays constant => RmlUi's cached
   handle stays valid => the window updates live. (Reimport counting unchanged.)

2. ext-window-field assets — the window texture is painted via an RCSS image()
   DECORATOR bound with data-style-decorator (the stage-dock pattern), NOT an
   <img src="{{ w.live_uri }}">: RmlUi does not substitute a data binding inside
   an img src, so the literal "{{ w.live_uri }}" was reaching the texture loader
   ("Could not load texture"). Also `contain` (was `cover`) so the whole window
   shows instead of cropping its center.

Verified: foot composites as a surface element in the window field and updates
live (a ticking clock); a 2nd window tiles with the focused one highlighted.
kernel + ext-window-field suites green; build-asan kernel green (no leak/UB).

Follow-up: a kernel regression test asserting the texture id is stable across
re-imports (no test caught this — RmlUi caching is the subtlety).

0 files changed, 0 insertions, 0 deletions