# 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`), а не дублювати магічне число, інакше вони
  розходяться, як тут.