docs(evidence): recover buffering camera projection path

docs/tomes/05-render.md

@@ -1258,6 +1258,27 @@ and `ICamera::GetTransformMatrix`, plus frustum/clip methods. These names prove
 that a transform-matrix interface exists, but give neither method slots nor a
 matrix convention; they must not be treated as a usable renderer ABI yet.
 
+### Buffering-camera projection path from static Terrain analysis
+
+A further headless-IDA review of the same GOG `Terrain.dll` identifies a
+concrete `CBufferingCamera` implementation path without requiring a live game
+process. Its method at RVA `0x4D740` copies exactly 64 bytes (16 dwords) into
+the component at offset `+0x10`. Its frame-preparation method at RVA `0x4D9C0`
+queries a viewport rectangle through a virtual method at `+0x3C`, derives its
+width, height, centre and an aspect ratio from that rectangle, and obtains
+projection data through the camera interface. Projection type `0` uses a
+component float at offset `+0x234` as an angle passed to `tan(angle / 2)`;
+projection type `2` obtains a five-float block through a virtual method at
+`+0x70`. Any other non-zero type raises `Not supported projection type`.
+
+This is sufficient to prove that original viewport and projection state are
+live camera inputs, rather than a fixed diagnostic projection. It does **not**
+yet prove matrix row/column convention, angle units, near/far field mapping,
+handedness, or the initial mission camera object. In particular, the exported
+string-labelled `ICamera::SetTransformMatrix` (RVA `0x4F830`) and
+`ICamera::GetTransformMatrix` (RVA `0x4F850`) are both obsolete-call stubs, so
+they are not a usable method ABI.
+
 `Land.msh` использует отдельный geometry-only bridge: validated `TerrainFace28`
 сохраняет source triangle order, а его positions и packed UV0 попадают в тот же
 static vertex/index upload path. Для текущего диагностического viewer XY bounds

docs/tomes/08-evidence.md

@@ -254,6 +254,20 @@ Terrain object. Следовательно, selector `18`, slot `+12` и global
 должны оставаться именованными evidence boundary до dynamic capture; считать
 `stdGetCurrentCamera2` getter-ом переданной camera было бы ошибкой.
 
+Повторный headless-IDA review той же GOG базы уточняет рабочий static contract
+`CBufferingCamera`. Метод Terrain RVA `0x4D740` копирует ровно 64 байта
+(16 dword) в component offset `+0x10`. Frame-preparation метод RVA `0x4D9C0`
+получает viewport rectangle через virtual slot `+0x3C`, выводит width, height,
+centre и aspect, а projection читает через camera interface. Для projection type
+`0` он использует float по component offset `+0x234` в `tan(angle / 2)`; для
+type `2` получает five-float block через slot `+0x70`; иной non-zero type
+завершается `Not supported projection type`. Это доказывает зависимость
+projection от live camera/viewport, но не row/column convention, единицы угла,
+near/far mapping, handedness или initial camera selection. Важно, что строки
+`ICamera::SetTransformMatrix` (RVA `0x4F830`) и
+`ICamera::GetTransformMatrix` (RVA `0x4F850`) ведут только в obsolete-call
+stubs и не дают usable ABI.
+
 Локальная IDA-база уточняет адреса этой связи: `stdGetCurrentCamera2` — это
 шестибайтный getter по RVA `0x4FD80`, который возвращает `dword` по RVA
 `0x7355C`. Единственный найденный initializer этого global — функция Terrain