[aside] storage-bloat-spike.md の「最大の成長項 = tag_event」結論が実測で陳腐化していた。

維持コスト試算で `scripts/measure-event-log.sh` を 2026-05-31 に再実行したところ、post_embedded(埋め込みベクトルを FLOAT[] event として保存)が event log の 62.8%(1.29MB / 全 2.06MB)を占め、tag_event(16.4%)を抜いて最大の成長項になっていた。doc(2026-05-28、§所見「どこが最初に効くか」)は「最初に支配的になるのは tag_event の行数累積」と結論しており、embedding 投入後の現実とズレている。

今回はコスト試算のスコープ外(容量はまだ volume の 0.2% で非緊急)なので触らない。

トリガー: storage 削減に着手するとき、または embedding 行数が volume を圧迫し始めたら — doc の支配項を embedding 基準に書き直す + 「vector を event log に verbatim 保存する」設計の是非(別 store / 量子化 / 再計算可能なら log から外す等)を再検討する。