refactor(instrumentation): add CPU counters and GPU timestamps to the renderer

[MAILLOTNathan]

Context

Describe what problems is encountered and why it has to be fixed

The performance audit is based entirely on static analysis — no measured
numbers exist yet (docs/PERFORMANCE_AUDIT_EVAN.md §Expected impact). Every
optimization issue in this folder is prioritised by engineering estimate, and
several GPU findings are explicitly marked LIKELY (GPU) and need confirmation.

Without instrumentation we cannot:

• prove which bottleneck dominates at a given object count,
• measure the effect of P0-01 …
  P1-07,
• detect regressions.

Audit reference: docs/PERFORMANCE_AUDIT_EVAN.md
§Instrumentation recommendations.

Priority level

P2 — Medium impact, high leverage. Cheap to add, and it is the prerequisite
for validating every other issue in this folder. Recommend landing early
despite the P2 label.

Description

Explain what this refactor should do

Add low-overhead instrumentation, disabled by default.

1. CPU timers in Renderer::drawFrame: preprocess (xrWaitFrame/
   xrBeginFrame/xrLocateViews), acquire
   (xrAcquireSwapchainImage/xrWaitSwapchainImage or
   vkAcquireNextImageKHR), per-view updateUniformBuffer /
   recordCommandBuffer / vkQueueSubmit, every fence wait, present
   (xrEndFrame/vkQueuePresentKHR). This separates CPU record time from GPU
   wait time.
2. Per-frame counters (also referenced by P0-01):
   visible meshes, draw calls, pipeline binds, descriptor binds, sync() calls,
   GPUMesh creations/destructions, vkQueueWaitIdle count.
3. GPU timestamps: a VkQueryPool, vkCmdWriteTimestamp around each eye's
   render pass, read back with VK_QUERY_RESULT_WITH_AVAILABILITY_BIT
   (never blocking).
4. Expose the data via a debug overlay or a log line every $N$ frames —
   not per mesh.
5. Document using RenderDoc, Nsight Graphics / Radeon GPU Profiler, and
   VK_LAYER_KHRONOS_validation + the performance/profiles layers.

Affected modules

List the modules that are affected by this refactor, so we can be careful while coding it

• Evan

  • Engine
  • Platform
  • Renderer
  • Device
  • Swapchain
  • Swapchain Context
  • Event

• Guillaume

• Utility

  • Math
  • Logger (must not flush per sample)
  • Utils
  • FileSystem

PoC (optional)

Frame at $N = 100$ and $N = 1{,}000$ and produce a CPU-vs-GPU breakdown plus a
per-frame counter dump.

Schemas / Designs (optional)

Metric	Mechanism
CPU phase time	std::chrono::steady_clock around phases
GPU pass time	VkQueryPool + vkCmdWriteTimestamp
Draw calls / binds	counters incremented in the record loop
Resource churn	counters in RessourceManager / GPUMesh

Possible conflicts

Talk about actual behavior and if it can affects another side of the code (so we can be careful while coding it)

• Must be off by default with negligible enabled cost; do not reintroduce
  the per-mesh logging problem (P0-01).
• GPU timestamp queries need a pool sized per frame-in-flight and correct reset
  handling.
• If the utility logger flushes per record, frame statistics must bypass it.