docs(evidence): correct Terrain camera receiver

docs/evidence/original_engine_hashes.md

@@ -19,6 +19,15 @@
 | `Terrain.dll` | `6d3e68f0e15b297f6c184af3113baf1f31e19c3326c18f0150dec659242ed667` | 708608 | Shared terrain/shade/world baseline |
 | `iron_3d.exe` / `iron_3d_p2.exe` | `f476af85c034a4b4f34f49d0806e4dff397b5da0ee26d382a7674231144979f7` | 36864 | Shared launcher binary |
 
+## GOG research baseline
+
+The canonical disassembly source is the windowed GOG installation, not the
+Part 1/Part 2 test installations. Its `Terrain.dll` is a distinct revision:
+
+| Binary | SHA-256 | Size | Notes |
+| --- | --- | ---: | --- |
+| `Terrain.dll` | `af87d1b2e728a0be73c52be3b44cc196ab46da7799f25a15d40f8c9b0b425ead` | 499712 | GOG camera receiver evidence; do not reuse Part 1/2 RVAs without a matching hash |
+
 ## Divergent binaries across Part 1 / Part 2
 
 Эти модули нельзя автоматически считать behavior-compatible между частями:

docs/reference/render-frame.md

@@ -50,6 +50,13 @@ the frame, and clears it before return. `sendEndOfRender` is a separate export
 at RVA `0x13D90`. This is frame-order evidence only: the camera ABI, matrices
 and viewport values still require dynamic capture or further decompilation.
 
+Receiver-side GOG Terrain evidence refines this contract. `stdSetCurrentCamera2`
+(RVA `0x4FD40` in Terrain SHA-256
+`af87d1b2e728a0be73c52be3b44cc196ab46da7799f25a15d40f8c9b0b425ead`) queries
+selector `18` on the supplied object and invokes slot `+12` on that result. It
+does not store the supplied pointer in `stdGetCurrentCamera2`; that getter
+returns a Terrain global populated by selector `8` during Terrain initialization.
+
 ## Parity risks
 
 - x87 precision and rounding;

docs/tomes/08-evidence.md

@@ -244,6 +244,16 @@ end-of-render callbacks вынесен также в отдельный `sendEnd
 Это доказывает порядок передачи camera и границы frame lifecycle, но не layout
 camera object, не матрицы projection/view и не значения viewport selectors.
 
+Отдельная проверка GOG `Terrain.dll` (`AF87D1B2E728A0BE73C52BE3B44CC196AB46DA7799F25A15D40F8C9B0B425EAD`,
+499 712 bytes) уточняет receiver side. `stdSetCurrentCamera2` находится по
+RVA `0x4FD40`: при инициализированном Terrain он требует у переданного объекта
+interface selector `18` и вызывает slot `+12` результата. Он **не** записывает
+переданный pointer в `stdGetCurrentCamera2`. Последний возвращает Terrain global,
+который внутренний initialization path устанавливает результатом selector `8` на
+Terrain object. Следовательно, selector `18`, slot `+12` и global selector `8`
+должны оставаться именованными evidence boundary до dynamic capture; считать
+`stdGetCurrentCamera2` getter-ом переданной camera было бы ошибкой.
+
 ### Vtable и interface negotiation
 
 Вызовы вида `object->vfunc(offset)` доказывают порядок slots, даже когда имя