[takecchi]

Issue #5409 を参照（案 A。#5402・#5406・#5407 の続き）。

内容

reset の発生を、日誌を引かずに見張れるようにする。読み取りだけで、書き込みと基準の保存は変えない。

• UsageAggregate（aggregate() の戻り、GET /usage の応答）に、任意の resets: [{layer, managerId, resets, lastResetAt?}] を足した。基準（層 × 担当）ごとの回数と最終時刻。
• 基準が1件でもあるときだけ欄を載せる（無ければ欄ごと無い）。reset の無い基準は回数 0・lastResetAt 無し（「数え直しが無い」と「基準が無い」を区別するため）。
• 日付に依らない現在値: from / to / site / tokenId では絞らず、layer / managerId だけで絞る（基準は日付を持たないため）。並びは層、managerId の順。
• インメモリ / fs / pg の3実装の aggregate() が、同じ関数（resetRowsOfBaselines）で作る。pg は usage_baseline を（絞り込み付きで）select。
• alteroid usage は、1回以上ある基準だけ 1 行ずつ出す（0 回は出さない。0 回だけ・欄なしなら出力は 1 文字も変わらない）。--json は無い現状のまま。
• apps/daemon/openapi.json を再生成した（pnpm -C apps/daemon build）。

既存クライアントへの影響

任意欄の追加だけで、既存の欄は変えていない。欄を知らないクライアントは無視でき、resets を読まない CLI の出力も変わらない。ただし基準が1件でもある台帳の応答には resets が載る（pg の「既存の応答を変えない」試験の鍵の一覧に resets を足した）。

案 B（reset の行へ「欠落ぶんで判定した」印を足す案）は入れない

schema を増やすので、A で足りるかを見てから。

試験

• 契約（verifyUsageResetsContract）を3実装に当てた: 数え直しの後に回数・最終時刻が読める、基準に reset が無ければ 0 回で最終時刻なし、layer / managerId で絞れる、日付で絞っても変わらない、該当が無ければ欄ごと無い。
• GET /usage の応答（絞り込み・日付に依らない）と、alteroid usage の表示（1 回以上だけ・0 回は出さない・導入前と出力が変わらない）。

変異の確認

• 基準の列挙（resetRowsOfBaselines が空を返す）にすると、契約の3実装（インメモリ・fs・pg）と GET /usage の試験が落ちた。
• CLI の表示（describeUsageResets を外す）にすると、CLI の表示の試験 2 本が落ちた。
• どちらも戻して全緑。

限界

判定そのものは推定で、誤って数え直しとみなす（過大）も拾えない（過少）もありうる。この口は、回数が増え続けていないかを見張るためのもの。過去分の台帳は補正しない。