書き込み系ミューテーションにレート制限と濫用対策を入れる

[TinyKitten]

背景

MobileApp のテレメトリ本番オプトインを検討中（TrainLCD/MobileApp#6982 の docs/telemetry-production-optin-risk.md）。書き込み系トークンはビルド時にバンドルへ埋め込まれる静的な共有シークレットで、認証方式そのものの見直しは #34 に切り出した。それとは別に、正規のクライアントが増えた場合・暴走した場合に基盤を守る層が要る。

現状

• リポジトリ内にレート制限の実装が見当たらない（rate_limit / throttle などで grep しても該当なし）。
• MobileApp 側はスロットルでクライアント 1 台あたり最大 1 秒 1 リクエスト（TELEMETRY_THROTTLE_MS = 1000）。バッチングもリトライ制御も無い。
• canary の母数では問題にならないが、本番 DAU では桁が変わる。

やりたいこと

サーバ側で受信レートの上限を持ち、超過分を落とす。落とし方はクライアントを壊さない形が望ましい（sendLocation は warning フィールドを既に返せるので、拒否ではなく間引きの合図に使える余地がある）。

検討したい軸:

• セッション単位 / トークン単位 / IP 単位のいずれで絞るか（複数併用か）
• 超過時の応答（HTTP 429、GraphQL errors、warning での通知のどれにするか）
• リングバッファと DB それぞれの保護（書き込みが詰まったときに WebSocket 配信まで巻き込まれないこと）
• 異常値の拒否（未来のタイムスタンプ、極端な座標・速度、同一セッションからの並行書き込み）
• 観測: 拒否数・レートをメトリクスかログで見られること

受け入れ条件

• 書き込み系ミューテーションに上限が入り、超過時の挙動がテストで固定されている
• 上限値が設定（環境変数 / config.toml）で変えられる
• 上限の既定値と、超過時にクライアントから何が見えるかが README に書かれている

優先度

本番オプトインの前提条件。#34 とセットで必要。