Record three-day supply acceptance and recovery checkpoint

docs/qa/P1_SUPPLY_CHAIN.md

@@ -45,10 +45,20 @@ make preview-supply
 | 有料購入・決済失敗・停止後出庫・返送容量・複数倉庫 | 84項目 PASS |
 | 商品UI・下書き・重複防止・待機購入Save復元 | 37項目 PASS、1280×720も実描画確認 |
 | 通常初期予算→実供給→食堂売上→配送途中保存 | 初日の35項目 PASS、1440×810の3タブを目視確認 |
-| 通常3営業日の締め・再仕入れ・最終保存 | 最終受入を実行中 |
+| 通常3営業日の締め・再仕入れ・最終Snapshot復元 | 45項目 PASS、終了コード0、SCRIPT ERRORなし |
+
+通常初期5,000G・資材50から、原料を合計120個／360G仕入れた。倉庫→厨房30便、厨房→食堂51便が完了し、食堂売上は毎日1,400G、累計4,200G、宿泊売上は累計800Gだった。給与は毎日645G、3日とも未払0・照合差0。3日目の決算後残金は26,115G、資材は4。配送途中の専用ディスクSave復元と5分再生の全状態一致、3日完了時のSnapshot復元を確認した。完全ログは `artifacts/supply-chain/normal-play.log`。
+
+大きな残金には受付の直接収入22,420Gが含まれる。この数字は供給・日次記帳の成立を示すもので、価格や利益バランスの合格ではない。今回の3日自動受入は、価格・営業Policyの通常UI、改善を怠った対照試遊、初見プレイヤーによる確認を代替しない。
 
 既存回帰は構成ターゲットを分割して実行した。`test-s0/s1/s2/s3/s6/mvp` の38本・3,389項目が成功終了し、`check`・`test-s4`・`test-s5`（旧保存fixture補正後のDefense再確認を含む）・`test-acceptance`・`test-ui`・`test-perf` も完了した。性能のsmokeは部品を直接合成する検証で、通常シーン全体の描画性能を示さない。
 
+## 長期運営の処理負荷
+
+本番Runtime付きの通し受入は、部品smokeより大幅に時間を要した。途中保存のコピーから8ゲーム分だけを隔離再生した短い計測では、Main付き合計479.8msのうちSnapshot生成52.3ms・決定性Digest276.8ms・購読UI82.4msだった。UIを外しても合計375.0msで、Snapshot＋Digestが331.2msを占めた。客2人・台帳37件・Snapshot約380KBでの値であり、3日目の代表値や描画fpsではない。
+
+主因はRuntimeが毎分全世界のSnapshotを再作成し、再帰的に正規化してSHAを計算する経路と判断する。物流は同じ8分で約4.5ms、施設／厨房は約0.3msだった。変更のない集約の再利用、画面更新頻度、履歴の増加に対する計測を後続課題にする。決定性の照合や保存検証を省いて高速化する変更は今回行わない。初日途中のSnapshotではイベント履歴が約166KB・単体Digest15.45msで最大だった。日数による劣化の程度は追加計測する。根拠は `artifacts/supply-chain/runtime-profile.log` と `runtime-profile-parts.log`。
+
 ## 残る課題
 
 - 正本の料理ポイント・食器・施設解禁との統一、仕入れ設定の継続自動発注、価格・サービス会計の調整は残る。