feat(enakgame): budget controller recommendations and analytics

EnakGame phase 9 of docs/tasks-enakgame.md (EG-901 to EG-903).

Budget Controller (EG-901, EG-902)
- GET /marketing/enakgame/budgets/:id/recommendation, GLOBAL budgets only: the
  multiplier (budget − realized) / (forecast − realized), within one step of 1,
  rounded down to two decimals, either way. Shows each game's new rules.
- POST .../recommendation/accept with the multiplier the admin saw: recomputed in the
  transaction, then one new ACTIVE version per game, the old one RETIRED, audited
  with source budget_controller and RECOMMENDATION_ACCEPTED on the budget.
- Migration 000112: base_config_id, multiplier and budget_id on
  game_reward_configs. Rules are always scaled from the admin's last version, so
  rounding does not compound and min/max are against what the admin set.
- Guardrails in game_budgets.thresholds: max_step_percent 10, min/max multiplier
  50-150%, cooldown_days 7 per organization. Provisional pending RFC §19.2 #4.
- RewardCalculator.Scale for the four reward types: amounts only, rounded down.

Analytics (EG-903)
- GET /marketing/enakgame/analytics/games and /analytics/economy over a range of
  Asia/Jakarta days (at most 366), from game_sessions and the wallet ledger.
- Migrations 000113 (game_sessions by organization and start) and 000114
  (wallet_transactions by organization and time, CONCURRENTLY).

The Postgres tests for accepting and analytics were not run: no test database here.
Migrations 000112-000114 have not been run anywhere.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/rfc-enakgame.md

@@ -804,6 +804,29 @@ membuat forecast = budget, lalu batasi dengan step maksimum dan min/max multipli
 §31). Rekomendasi ditampilkan ke admin. Bila disetujui, admin membuat **reward config
 versi baru** (§5.2). Tidak ada perubahan reward tanpa versi baru dan tanpa audit.
 
+Implementasi (EG-901, EG-902):
+
+- Hanya budget `GLOBAL` (yang membayar base reward). Budget `EVENT` ditolak; tambahan
+  event diatur di event-nya.
+- Target = (budget − realized) / (forecast − realized), karena hanya biaya ke depan yang
+  ikut berubah bila reward diubah. Target dibatasi ±step dari 1 lalu dibulatkan ke bawah
+  ke dua desimal. Bisa turun **atau naik**.
+- Multiplier tiap game diukur terhadap **base**: versi terakhir yang ditulis admin.
+  Versi buatan Budget Controller menyimpan `base_config_id`, `multiplier`, dan
+  `budget_id` (migrasi 000112), dan aturannya selalu dihitung ulang dari base (dibulatkan
+  ke bawah), jadi pembulatan tidak menumpuk. Min/max berlaku untuk multiplier kumulatif
+  ini. Admin yang menulis versi baru memulai base baru di 1.
+- Cooldown per organisasi: setelah rekomendasi diterima, rekomendasi berikutnya baru bisa
+  diterima setelah `cooldown_days`.
+- Guardrail disimpan di `game_budgets.thresholds` bersama warning/critical:
+  `max_step_percent` (default 10), `min_multiplier_percent` (50),
+  `max_multiplier_percent` (150), `cooldown_days` (7). Nilai default ini **sementara**,
+  menunggu §19.2 #4.
+- Terima: `POST /budgets/:id/recommendation/accept` dengan `multiplier` yang dilihat
+  admin. Rekomendasi dihitung ulang di dalam transaksi; bila berbeda, tidak ada yang
+  berubah. Satu transaksi: versi lama `RETIRED`, versi baru langsung `ACTIVE`, audit
+  `source = budget_controller` per config dan `RECOMMENDATION_ACCEPTED` di budget.
+
 `GET` metrik cukup cepat untuk dashboard selama index di §5.7 ada. Bila nanti lambat,
 tambahkan snapshot harian, bukan cache yang di-invalidate.
 
@@ -833,7 +856,8 @@ Prefix `/enakgame` dipakai karena `/customer/games` sudah dipakai alur spin lama
 | Games | CRUD, `PUT /:id/status` |
 | Reward configs | `POST /games/:id/reward-configs` (versi baru), `POST /reward-configs/:id/activate`, `GET` daftar versi |
 | Events | CRUD, `PUT /:id/status` |
-| Budgets | CRUD, `GET /:id/metrics`, `GET /:id/recommendation` |
+| Budgets | CRUD, `GET /:id/metrics`, `GET /:id/recommendation`, `POST /:id/recommendation/accept` |
+| Analytics | `GET /analytics/games?from=&to=&game_id=`, `GET /analytics/economy?from=&to=` (tanggal Asia/Jakarta, maks 366 hari) |
 | Vouchers | CRUD, `POST /:id/codes` (impor CSV), `GET /:id/codes` |
 | Redemptions | `GET` list, `GET /:id` dengan atribusi cost |
 | Sessions | `GET` list + filter `flagged` |
@@ -974,7 +998,8 @@ Dari PRD §43:
 1. **Pembulatan reward.** Usulan §8: bulatkan ke bawah, mengikuti K6.
 2. **Event stacking.** Sementara memakai default PRD §16.
 3. **Budget exhaustion policy**, untuk budget global dan budget event.
-4. **Threshold Budget Controller.**
+4. **Threshold Budget Controller.** Sementara memakai default di §10 (step 10%,
+   multiplier 50%–150%, cooldown 7 hari), bisa diubah per budget.
 5. **Timeout reservasi voucher.** Dengan §7.4, hanya relevan untuk voucher eksternal.
 
 Tidak ada yang memblokir langkah 1–7 di §17. Nomor 3 dan 4 harus diputuskan sebelum langkah