Retain and cache PRK.Client window chrome rendering

Replace repeated software reconstruction and offscreen composition of static UI window chrome with retained cached raster layers. Rebuild cached chrome only when visual inputs such as size, render scale, graphics archive, tint, opacity, or chrome attributes change. Preserve damage clipping, transparency, occlusion behavior, and pixel output. Acceptance criteria: - Repeated child-only damage does not reconstruct window nine-slices or their two translucent layers. - Cache lifecycle is bounded and disposed safely when the renderer is disposed. - Rendering regression tests cover cache reuse and invalidation while existing UI tests remain green. - The client builds successfully and is ready for an equivalent before/after profile. Profiling update: - Damage-cropped retained chrome reduced worst observed UI-paint occupancy from about 83% to 58%, but this is not yet sufficient. - Window dragging remains a severe FPS regression because fractional device-position changes produce repeated exact-transform cache builds. - Framebuffer snapping removed drag-time chrome rebuilds (0% BuildWindowChrome in the final drag trace), but the monolithic CPU UI surface still forced large old/new-area redraws. - Removing the normal window composition layer was tested and rejected: EndLayer fell from 19.2% to 1.3%, but total UI paint worsened to 68.9% because direct full-window image copies dominated. - The failed layer-removal experiment was reverted. A drastic drag improvement now requires retained per-window backing surfaces/composition rather than further tuning of the flattened surface. Pull request: #2657 https://git.project-rk.com/prk/engines/pulls/2657