訪問済みタイル(ミニマップ)データのビットパック圧縮によるstate保存・転送の高速化

1. 目的:
256×256のワールドマップやサブマップでは、既訪問タイルを『x,y』文字列やタイル座標配列として state に蓄積している。探索が進むほどこの配列はJSONエンコード/デコードコストが増大し、セッションバッファ保存・DB永続化・Ajax差分レスポンスのすべてで遅延要因になる(特にミニマップ表示範囲が広いシナリオで顕著)。これを1タイル=1bitのビット配列形式に圧縮し、全操作(移動・戦闘後の状態保存・ページ再読込)を高速化する。

2. 具体的な仕様:
- サーバー側に rpgsf_pack_visited_bits(array $visitedTileKeys): string を追加。256×256=65536タイル分を1ビットずつ管理し、8192バイトのバイナリをbase64エンコードして保存(1マップあたり約10.9KB固定長。従来のタイル座標配列JSONは探索が進むと数十KB〜100KB超になり得るため大幅圧縮)。
- state構造に state['visited_bits'][$map_id] (base64文字列) を新設。プレイ中はPHP側でバイト文字列としてデコードしたまま保持し、タイル到達時にビットを立てて、セッションバッファ保存時のみbase64へ再エンコードする(既存の『セッションバッファ経由のDB保存間引き』の仕組みに相乗り)。
- マップ移動Ajaxの差分レスポンス(既存の差分化の仕組みを踏襲)には、今回新たに立った訪問ビットのタイル座標のみを delta として返却し、クライアントはUint8Arrayのビットマップに反映してミニマップの該当タイルだけ再描画する。フルbase64文字列は初回ロード時とロード/セーブ復元時のみ送信する。
- クライアントJSのミニマップ描画で、これまでの配列/Setの includes 判定をUint8Arrayのビット判定(1バイトにつき8タイル)に置き換え、描画ループを高速化する。

3. 既存機能との整合:
- 旧形式(visited配列のみ)を持つ進行中セーブ・共有シナリオは、読み込み時に1回だけ rpgsf_pack_visited_bits() で新形式へ自動変換し、以後はvisited_bitsで保存する。旧フィールドが存在しない場合は空ビット配列で初期化するだけなので、既存の冒険の書スロット・自動保存・共有プレイいずれも壊さない。
- Ajaxレスポンスの差分方式・ゲーム進行ログ・戦闘・ショップ等の既存処理には手を加えず、ミニマップ/訪問済みタイル管理部分だけを対象にした局所的な最適化とする。
- APIレスポンスのJSON構造にvisited_bitsフィールドを追加するのみで、既存クライアントコードが未対応でも従来のvisited配列フォールバックを残し後方互換を保つ。