docs: привести README и API.md в соответствие с живым стендом

Оба файла описывали состояние, которого больше нет, и содержали ошибки,
из-за которых внешний разработчик не собрал бы рабочий фронт:

- README описывал Phantom, swap ввод/вывод (POST /api/pump/swap), STUB-ключи
  и Фазу 1 — ничего этого в index.html нет. Указан нерабочий API base
  (smart-updown.binom.pw вместо testfront.binom.pw) и адрес контракта FMM….
  «Ставка через поллинг» — поллинга нет, события по WS.
- API.md держал раздел «часть ставок зависает без исхода» со статусом
  «не исправлено» — баг закрыт 14.09.2026 в контракте. По этой доке писали бы
  обходной код под проблему, которой нет.

README переписан под фактический index.html: HTTP-шлюз без Phantom,
сценарий кошелёк→фаусет→ставка→WS-исход, три исхода, правило 409.
Секция API.md заменена на «Ничья при exitPrice == entryPrice» (штатный
исход, доля ~трети), историческая сноска на SEC-9 сохранена.

Проверено: полный сценарий снаружи по новой доке проходит
(кошелёк → фаусет 10000 → ставка id=44 → исход по балансу).

README.md

@@ -1,46 +1,46 @@
 # test-front — технический тестовый фронт (Binary Rocket)
 
-Чисто технический веб-дашборд для **ручного тестирования механики экономики**
-(пополнение фантиками → ставка → вывод) БЕЗ Unity. Только кнопки + вывод технической
-информации и лог. Никакой «красоты» — он для гонок сценариев.
+Чисто технический веб-дашборд для **ручной проверки механики** через HTTP-шлюз:
+кнопки + лог. Без Phantom, без swap, без вывода средств — только постановка ставок
+фантиками и наблюдение за событиями.
 
 ## Зачем
 
-Unity-фронт (`fun-game-front2`) хорош для продакшена, но для быстрых итераций по
-экономике (swap ввод/вывод, ставка фантиками, поллинг результата) он тяжёлый.
-Этот фронт дёргает те же эндпоинты бэкенда и даёт мгновенный отклик.
+Технический пульт для проверки контракта «вручную»: быстро прогнать сценарий
+«создать кошелёк → пополнить тестовым фаусетом → поставить → дождаться исхода».
+Полный контракт API (HTTP + WS, поля событий, коды ошибок) — **[API.md](API.md)**.
 
 ## Возможности
 
-- Подключение Phantom, показ адреса.
-- Отображение баланса: **фантики** (токен Binary Rocket) + SOL.
-- **Пополнить** — swap SOL→фантики через `POST /api/pump/swap` (подпись в Phantom).
-- **Вывести** — swap фантики→SOL.
-- **Ставка** (вверх/вниз) в фантиках через контракт: `GET /api/state` →
-  `POST /api/bet` → **события по WebSocket** (`bet_open` при постановке, `bet_closed` при
-  расчёте). Поллинг не нужен: шлюз закрывает ставку сам по таймеру.
-  Полный контракт API (HTTP + WS, поля событий, ошибки) — **[API.md](API.md)**.
+- Поля в шапке: **Шлюз (API)**, **WS URL**, **Адрес**.
+- **Создать кошелёк** — генерирует новый custodial-адрес через шлюз.
+- **Пополнить кошелёк** — тестовый фаусет: наливает SOL и фантики.
+- **Сделать ставку** — `POST /api/bet` (`side` `UP`/`DOWN`, `amountUnits`).
+- События по **WebSocket** (`price`, `bet_open`, `bet_closed`) — поллинга нет.
 - Лог всех действий + кнопки «Копировать» / «Очистить».
 
 ## Как пользоваться
 
-1. Открыть `index.html` (или раздать через любой статик-хостинг / nginx).
-2. В шапке задать конфиг:
-   - **API base** — бэкенд (напр. `https://smart-updown.binom.pw`).
-   - **RPC** — публичный Solana RPC (напр. `https://rpc.solanatracker.io/public`).
-   - **Program** — адрес контракта (по умолч. `FMM...`).
-   - **Token mint** — адрес mint наших фантиков.
-3. Подключить Phantom.
-4. Гонять сценарии: пополнить → сделать ставку → дождаться исхода → вывести.
+1. Открыть `https://testfront.binom.pw/` — `index.html` отдаётся из куба
+   (namespace `game`). Поле «Шлюз (API)» можно оставить пустым — фронт возьмёт
+   свой адрес.
+2. Нажать **Создать кошелёк** — в поле «Адрес» появится custodial-адрес.
+3. Нажать **Пополнить кошелёк** — тестовый фаусет нальёт SOL и фантики.
+4. Выбрать сторону (`UP` / `DOWN`) и сумму (в пределах `minAmountHuman` /
+   `maxAmountHuman` из `/api/state`: `100` … `10000` фантиков) → **Сделать ставку**.
+5. Результат придёт сам по WS примерно через `expirySeconds` (15 с).
 
-> Примечания
-> - Фронт читает/пишет токен-аккаунты через RPC; для Token-2022 decimals читается из mint.
-> - STUB-ключи create_bet пока зашиты под SOL-версию контракта. Когда контракт переведут
->   на токен (Фаза 1), этот блок обновить под токеновые ключи.
-> - API base должен отдавать CORS (nginx-прокси), иначе браузер заблокирует fetch.
+Три возможных исхода ставки:
+- **выиграл** — `statusName: "payout_done"`, выплата с множителем;
+- **проиграл** — `statusName: "house_won"`, ставка остаётся в ваулте;
+- **возврат при ничьей** — `statusName: "refunded"`, залог возвращён ровно
+  суммой ставки без множителя (подробнее — [API.md](API.md), раздел
+  «Ничья при `exitPrice == entryPrice`»).
+
+> Правило: **одна открытая ставка на адрес** — вторая ставка с того же адреса
+> получит `409`. Дождитесь `bet_closed` по WS, прежде чем ставить снова.
 
 ## Статус
-- [x] каркас: балансы, swap ввод/вывод
-- [x] ставка вверх/вниз через контракт (поллинг)
-- [ ] перевести подпись под токеновую версию контракта (после Фазы 1)
-- [ ] реальный провайдер цены вместо RandomPriceSource (за нами)
+
+- [x] каркас: кошелёк, фаусет, ставка, события по WS
+- [x] контракт: возврат при ничьей (`exitPrice == entryPrice`)