進行ログの上限件数トリムによるstate保存・通信ペイロード削減で全体を高速化

1. 目的:
プレイ時間が長くなるほど state['log']（進行ログ配列）が際限なく蓄積し、state_jsonのサイズが肥大化する。これによりマップ移動・戦闘のAjax応答（stateのJSONエンコード/デコード）、MySQLへのstate_json保存・読込、冒険の書セーブ/ロード、localStorage/Service Workerキャッシュ経由の再開処理などすべての通信・保存処理が徐々に重くなっている。ログ自体は直近の出来事しか画面表示に使われていないため、上限件数でトリムすることでペイロードを軽量化し、既存の高速化施策（Ajax差分化・即時返却・メモリキャッシュ）の効果を長時間プレイでも維持する。

2. 具体的仕様:
- lib.php の rpgsf_log($state, $message) 関数を修正し、ログ追加後に count($state['log']) が上限（例: 80件）を超えた場合、array_slice で古い方から削除して直近80件のみを保持する。
- 既存の進行中セーブ（既にログが80件を超えている旧データ）についても、rpgsf_load_or_create_save() でstateを読み込んだ直後に同じトリム処理を1回適用し、後方互換を保ちながら肥大化データを自動的に縮小する。
- マップ移動・戦闘のAjax応答でstateまたはlogをクライアントに返す箇所は、DB保存用の80件とは別に、画面表示に必要な直近20〜30件のみを返却対象とし、レスポンスサイズをさらに削減する（DB保存側の80件はそのまま維持し、表示上の見え方は変えない）。
- 冒険の記録エンドカード・旅の記憶帳・図鑑の討伐数/宝箱数/訪問島などの集計は、ログ配列ではなく別途保持している専用カウンタ・配列（kill_count, chest_count, visited_islands等）を参照している前提のため、ログのトリムによる影響を受けない。

3. 既存機能との整合:
- ログ上限は十分な件数（80件）を確保するため、進行ログ表示・シナリオ再開直後の文脈把握には支障が出ない設計とする。
- rpgsf_log() は全てのイベント（NPC会話、宝箱、戦闘、レベルアップ等）から共通で呼ばれる関数のため、一元的な変更で全経路に反映され、既存のマップ移動・戦闘・セーブ/ロード・共有プレイの挙動は変わらない。
- DBスキーマ変更は不要（既存のstate_json MEDIUMTEXTカラムのみで対応）。