Utility and polishing + bag fixes

docs/worklog/11-payzone-deposit-flight-unified.md

@@ -0,0 +1,26 @@
+# PayZoneC: уніфікація депозит-флайту з ResourceC (2026-08-12)
+
+`playDepositFlight` (політ токена з HUD в Pay Zone) використовував
+окремий TweenJS-based шлях, не звʼязаний з новою логікою `ResourceC`:
+мав ротейт (`mesh.rotation.y += 0.3`) і стартовий `scale=1` (дефолт
+свіжого `ResourceC.createVisual()`, без жодного стиску).
+
+- **Ротейт прибрано** повністю (користувач: "ротейту не має бути").
+- **Компенсація перспективи** — та ж сама техніка, що й у
+  `ResourceC.toTarget`, але в ПРОТИЛЕЖНИЙ бік: цей політ стартує БЛИЗЬКО
+  до камери (HUD-анкер) і летить ДАЛІ (Pay Zone, зазвичай далі від
+  камери) — без компенсації токен би візуально ЗМЕНШУВАВСЯ на льоту.
+- **⚠️ Знайдений і виправлений баг: токен був значно більшим за ресурс з наземної анімації**
+  Причина: `ResourceC.createVisual()` не проходить через `SHRINK_AMOUNT`-
+  стиск (той стосується лише "живих" `FlyingResource` з баунсом) — токен
+  стартував з `scale=1`, тоді як ресурс, який щойно долетів на те саме
+  місце з `ResourceC`, виглядав як `0.85`. **Фікс**: `RESOURCE_ICON_BASE_SCALE
+  = 1 - SHRINK_AMOUNT` (0.85) винесений з `ResourceC.ts` як `export`,
+  `PayZoneC` множить на нього. Плюс окремий `DEPOSIT_FLIGHT_SCALE_MULTIPLIER`
+  (зараз `1`, користувач підкрутив до `0.3` в UI-сесії) — локальний
+  тюнер розміру САМЕ цього польоту, не торкаючись спільної константи
+  (яка вплинула б і на "земля->юай" анімацію).
+- **Урок**: коли два різні контролери візуально показують "той самий"
+  ресурс в різних сценах польоту — тримати спільну константу базового
+  розміру (`export`), а не дублювати магічне число, інакше вони
+  розходяться, як тут.