Add the renderer process

The renderer becomes two programs: the adapter (t5deRenderEngine.dll, 32-bit, in IMVU's process) and a 64-bit renderer process (t5de-renderer.exe) drawing with Diligent Engine, fetched with FetchContent and pinned. For now a spike: the adapter starts the renderer process for each engine and signals each frame through a shared memory channel, and the renderer process draws a box into a child window in the client's 3D view.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/architecture.md

@@ -0,0 +1,47 @@
+# Architecture
+
+The renderer is two programs:
+
+- **The adapter**, `t5deRenderEngine.dll` (32-bit, `adapter/`): a renderer plugin IMVU Classic loads in place of its
+  OpenGL renderer (selected by the `t5de-renderer` patch in the `t5de` repository). It implements IMVU's
+  `PiRenderEngine` interface (`include/t5de/imvu/`, `docs/interface.md`) and passes what the client draws to the
+  renderer process. It stays thin: IMVU's process is 32-bit (4 GB of address space shared with Python, Gecko and
+  IMVU's own code) and tied to Visual C++ 2010's ABI.
+- **The renderer process**, `t5de-renderer.exe` (64-bit, `renderer/`): draws, with
+  [Diligent Engine](https://github.com/DiligentGraphics/DiligentCore) (Apache-2.0). Being 64-bit and separate, it can
+  use any modern API and library, isn't limited by the client's address space, and can crash without taking the
+  client down.
+
+Why Diligent: one API over Direct3D 11 (every Windows PC, and software rendering on machines without a graphics
+driver), Direct3D 12 and Vulkan (ray tracing, mesh shaders), and WebGPU (browsers, for a possible future client).
+It's built with CMake and fetched by `FetchContent`, pinned to a commit (`renderer/CMakeLists.txt`); only the
+Direct3D 11 backend is built for now.
+
+## How they talk
+
+`include/t5de/protocol/` is shared by both builds, so it uses fixed-size fields only. For each engine the client
+creates (each 3D view, and again on room changes), the adapter:
+
+1. creates a shared memory channel (`Local\t5de-renderer-<pid>-<n>`) holding IMVU's window handle and a frame
+   count, and an event set after each frame;
+2. starts `t5de-renderer.exe --channel <name> --parent <pid>` from its own folder;
+3. sets the event at each `endRendering`, and sets `closing` when the engine is destroyed.
+
+The renderer process draws into a child window it creates inside the client's window: window handles are valid in
+every process, and Windows allows child windows across processes (Chrome's GPU process works this way). The child
+is disabled so mouse input goes to the client's window under it, and the adapter gives the client's window
+`WS_CLIPCHILDREN` so the client's own drawing stays out of it. The process exits when the engine is destroyed or the
+client exits.
+
+## Status
+
+A spike: the adapter still has IMVU's Direct3D 9 engine draw the scene (the pass-through), and the renderer process
+only draws a box in the 3D view's corner, pulsing with the client's frames. It proves the risky parts: drawing into
+the client's window from another process, keeping in step with the client's frames, and mouse input still reaching
+the client. Next: the protocol carrying the frame's calls and resources, and the renderer process drawing the scene.
+
+## Building
+
+Two presets, one per architecture: `cmake --workflow --preset adapter` (32-bit, with the tests) and
+`cmake --workflow --preset renderer` (64-bit; the first configure fetches and builds Diligent). Both programs go in
+the client's folder.