perf: account for the device memory the renderer holds

Stage 0 of the roadmap asks for a memory baseline before any more
optimisation, and explicitly not from RSS: the allocator and the driver
both retain high-water memory that RSS cannot tell apart from live
resources.

`gpu-live` counts from the sizes this renderer allocated, in the
categories large enough to decide where the next fix goes:

    slots  total  shadow  targets  text_atlas  wire_arena  block_geometry

It is partial by construction and says so, rather than presenting itself
as a total. Hatches, images, meshes and Face3D are not counted yet.

Three of the numbers needed a size that was not reachable before: the
block-geometry chunk records its bytes at build because in storage mode
the buffer belongs to the bind group, the arena exposes its allocation
rather than its occupied prefix — headroom is what a budget has to answer
for — and the text atlas reports its `R8` texel count.

Emitted only when a number moves. `prepare` runs thousands of times in a
session and these change a handful of times, so a per-frame line would
bury the log it is meant to explain.

This answers the question the previous fix left open: whether the arena's
52 MiB per slot, the 16 MiB shadow map every slot allocates whether or not
shadows are on, or the render targets dominate once a paper layout has
four or five viewports on screen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/scene/pipeline/text_gpu.rs

@@ -221,6 +221,11 @@ pub struct TextAtlasGpu {
 }
 
 impl TextAtlasGpu {
+    /// Device bytes this atlas holds. `R8`, so one byte per texel.
+    pub fn gpu_bytes(&self) -> u64 {
+        u64::from(self._texture.width()) * u64::from(self._texture.height())
+    }
+
     /// Bind-group layout for group 1: `{ R8 atlas texture, linear sampler }`.
     pub fn bind_group_layout(device: &wgpu::Device) -> wgpu::BindGroupLayout {
         device.create_bind_group_layout(&wgpu::BindGroupLayoutDescriptor {