phase 4: connectrpc on the gateway authenticated edge

Replace the native-gRPC server bootstrap with a single
`connectrpc.com/connect` HTTP/h2c listener. Connect-Go natively
serves Connect, gRPC, and gRPC-Web on the same port, so browsers can
now reach the authenticated surface without giving up the gRPC
framing native and desktop clients may use later. The decorator
stack (envelope → session → payload-hash → signature →
freshness/replay → rate-limit → routing/push) is reused unchanged
behind a small Connect → gRPC adapter and a `grpc.ServerStream`
shim around `*connect.ServerStream`.

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

docs/FUNCTIONAL_ru.md

@@ -138,9 +138,10 @@ Throttle-переиспользование на стороне send означ
 ### 1.4 Поиск сессии для каждого запроса
 
 Когда у клиента есть идентификатор устройства-сессии и приватный ключ,
-каждый аутентифицированный вызов — это подписанный gRPC-запрос к
-gateway. Gateway — единственный компонент, который видит подпись
-запроса; backend доверяет вердикту gateway.
+каждый аутентифицированный вызов — это подписанный запрос к gateway
+по аутентифицированному edge-листенеру (Connect / gRPC / gRPC-Web на
+одном HTTP/h2c-порту). Gateway — единственный компонент, который видит
+подпись запроса; backend доверяет вердикту gateway.
 
 Gateway нужен публичный ключ сессии для проверки подписи, поэтому
 каждый аутентифицированный запрос разрешает устройство-сессию через
@@ -618,10 +619,10 @@ Wire-формат команд, приказов и отчётов — собс
 
 ### 6.2 Роль backend: pass-through с авторизацией
 
-Signed-gRPC-конвейер для in-game-трафика использует три message
-types на аутентифицированной поверхности — `user.games.command`,
-`user.games.order`, `user.games.report` — у каждого типизированный
-FlatBuffers-payload. Gateway транскодирует FB-запрос в JSON-форму,
+Подписанный конвейер аутентифицированного edge для in-game-трафика
+использует три message types на аутентифицированной поверхности —
+`user.games.command`, `user.games.order`, `user.games.report` —
+у каждого типизированный FlatBuffers-payload. Gateway транскодирует FB-запрос в JSON-форму,
 которую ждёт backend, форвардит её REST'ом в соответствующий
 `/api/v1/user/games/{game_id}/*` endpoint, после чего транскодирует
 JSON-ответ обратно в FB перед подписью.
@@ -697,9 +698,10 @@ notification-каталог явно их опускает
 
 ### 7.1 Состав
 
-В составе: gRPC-стрим, который клиент открывает к gateway,
-bootstrap-событие, фрейминг форварднутых событий, control-канал
-backend → gateway, который производит эти события.
+В составе: server-streaming-подписка, которую клиент открывает к
+gateway (Connect / gRPC / gRPC-Web фреймы все маршрутизируются на
+одну точку), bootstrap-событие, фрейминг форварднутых событий,
+control-канал backend → gateway, который производит эти события.
 
 Вне состава: каталог видов событий — см.
 [Раздел 8](#8-уведомления-и-почта) для notification-стороны и