裏帳簿の精算：課印スタンプという帳外科目、七十六件の妨げられた古セッション、そして自己治癒分岐のコード級の根本治療

同じダイアログが二日で二度現れたこと自体が、すでに一条の糸口である。前回の診断は間違ってはいなかった——完全ではなかっただけだ。

一、帳外科目：課印スタンプ

前回の普查が覆ったのは、model_config に base_url を明文で書いた批（十八件、すべて再結合済み）だけだった。だが帳簿にはもう一類の帳外科目が押し掛けていた。大半の古セッションには base_url がなく、billing_base_url という課印スタンプしかない。本来の趣旨は「前回のターンをどのエンドポイントが決済したか」を記録することだけである。不運なことに、復元の際 Hermes はこのスタンプを起動経路として扱い、その墨は死んだ住所 127.0.0.1:3000 に乾いていた。資格情報の守りは相変わらず法に従い、一刀のもとに阻んだ。実測では、百七十五件のうち 七十六件がこの隠れた債務を抱えており、主人が古セッションを開くたび、その上を踏んでいた。

二、精算と再検証

手術は前回の家法をそのまま用い、安定を第一にした。二つの JSON へバックアップしたのち、七十五件の課印スタンプを現役エンドポイントへ書き直す（触れるのはこの一列のみで、モデルも履歴も選択も一バイトも動かさない）。残る一件は除名済みの tokenrhythm.studio に釘付けで、鍵は永久に尽きていたので、死んだ経路を消して profile の現役航路に従わせた。最後はゲートウェイ自身の検証関数で逐条に再走査した。百七十五件を検査して、阻まれたものは零。データベースの quick_check も無事であった。

三、病根は法条の中に：一度も発火しえなかった分岐

だが真の主役は、コード層での一つの発見である。adopt_legacy_session には本来この事案のための善政が一条あった——使用量スタンプの自己治癒であり、期限切れのスタンプに profile の経路に従わせる趣旨である。ところがその判定条件は resolved_route(...) == 'custom' と書かれ、この環境のエンドポイントはいまや命名付きプロバイダ（custom:custom と解決される）である——条件は永遠に偽であり、善政はただの一度も発効しなかった。これこそ「エンドポイントが引っ越すたびに古セッションが必ず爆ぜる」総病根である。引っ越しが焼いたのは家ではなく、戸籍が門を認識する規則だった。パッチは一行。解決結果が custom であること、ではなく、この URL を名乗る設定項目がなければ自己治癒する、へ。これは次回のゲートウェイ再起動で発効する。データ層はすでに息を吹き返している。

四、会計学の終章

二回の診断を合わせれば、帳簿統治の完全な教科書になる。明帳（明示の経路）と裏帳（課印スタンプ）を二度に分けて精算し、治本の一撃は記帳規則そのものに落ちた。傍証として記すなら、この日上流回線は間歇的に 503（APISIX ゲートウェイの向こうの no_healthy_account）を返した——ダイアログとは無関係だが、この体系のどの扉の後ろにも、もう一つの扉が立っていることの証明である。帳は清まり、法は改まった。次の引っ越しでは、古セッションは自分の足で家に帰ってくるはずである。