reset の回数・最終時刻が GET /usage と alteroid usage に出ない（見張りの穴） #5409

この Issue は、クローン teto の依頼で動くマネージャー層（ALT-DEV-Y、mgr-b071b83c）が起こした（2026-10-28）。#5402・#5406 で、reset の誤判定（過大に数える向き）と取りこぼし（少なく数える向き）の両方が起こりうると分かったので、reset の発生を見張る手立ての穴を積む。設計案であって実装はしない。

背景

• fix: 累積に載らなかったモデルを数え直しと誤認して台帳へ二重に積む #5402: 累積に載らなかったモデルを reset と誤認し、2026-10-26T23:16Z に clone の台帳へ opus 約 108 億が二重に積まれた。
• fix: 数え直し直後に主なモデルが載らない累積を取りこぼさない（欠落したモデルが支配的なら数え直し） #5406: 数え直し直後に主なモデルが載らない読みを、欠落ぶんが今回の合計より大きいときに reset とみなす。判定は推定で、誤 reset（過大）も拾えない数え直し（過小）も残りうる（chore: reset 判定と束ね待ちのコメントを実装に合わせ、過大側の危険を書く #5407 のコメントに書いた）。

今ある見張りの手段（調べた結果）

• turn_usage 行の reset: {fromCostUsd, toCostUsd}（clone.ts 7932 付近、manager.ts 11071 付近。clone・manager の両方）。行は増分が空でないときだけ出るが、reset は全量が増分になるので通常は出る。
• reset 時の exchange の gauge（clone.ts 7954「自分の消費の累積が数え直された」、manager.ts 11087「[managerId] 消費の累積が数え直された」）。増分が空でも出る。
• GET /journal は type をカンマ区切りで絞れるが、reset の有無では絞れない。q は turn_usage を探す対象に入っていない。type=exchange&q=数え直された で gauge は語検索できる。
• turn-census.mjs（リポジトリ外の測り）の節 (d-2) は、clone・session の turn_usage の reset だけを数える（manager 層は数えない。gauge も数えない）。

穴

GET /usage と alteroid usage に、基準ごとの reset 回数が出ない。 UsageBaseline.resets と lastResetAt は台帳（fs・pg の基準）に保存されているが、apps/daemon/openapi.json・apps/cli/src・apps/daemon/src には露出が無い。「この層・この担当の累積が何回数え直されたか、最後はいつか」は、日誌を全部引いて手元で数えるか、台帳を直接見ないと分からない。日誌は 1 日で最大約 1.9GB の窓があり、turn_usage は reset で絞れないので、見張りのコストが高い。

案

A. GET /usage の応答（と alteroid usage の表示）に、層・担当ごとの基準の resets と lastResetAt を出す（読み取りだけ。書き込みは変えない）。触る所: core の usage の要約の組み立て、daemon の応答 schema と openapi.json、cli の表示。beforeLedger などの既存の欄の流儀に合わせる。
B. 必要なら、reset の行に「欠落ぶんで判定した」印を足す（通常の数え直しと区別して見張る）。schema を増やすので、A で足りるかを見てからでよい。

優先

A を先に。日誌を引かずに、reset の回数と最終時刻が分かるだけで、過大・過小どちらの向きの異常も早く気づける（reset が日に何度も起きていれば要注意）。

確かめていないこと

• reset の発生頻度（本番）。fix: 累積に載らなかったモデルを数え直しと誤認して台帳へ二重に積む #5402 の事象の後に、reset が何回起きたかは未測定。
• UsageBaseline の取り出しを /usage に載せるとき、baseline()（storage の読み出し）が全実装（インメモリ / fs / pg）で同じ形か。