[aside] posts_view 移行で skill の例 SQL が ISO-8601 文字列の created_at に乗った ── time-window の interval 演算を足すと型エラーになる latent gotcha

PR #354(dev-work skill の例 SQL を posts_current → posts_view へ移行)で生じた、今回 caveat を足さなかった seam。

- 事実: `posts_view.created_at` / `updated_at` は ISO-8601 の VARCHAR(get_schema 確認)。対して `posts_current` は naive TIMESTAMP。今回 8 ファイル 12 クエリを posts_view に寄せた。
- 移行したクエリ自体は `ORDER BY created_at` / 文字列等値比較だけなので無害(ISO-8601 は辞書順 = 時系列順なので文字列比較が正しく効く)。
- だが将来「直近 N 日」のような **interval 演算**(`created_at > now() - interval '7 days'`)を posts_view 上で書くと、VARCHAR と timestamp の演算で型エラーになる。`created_at::timestamp` cast か `posts_current`(typed timestamp)に戻す必要がある。

→ 触らない判断: PR #354 は既存例の機械的移行が scope。今ある例は interval 演算をしないので caveat を足さなかった。
→ 想定インパクト / トリガー: posts_view を起点に time-window 集計クエリを新規に書くとき。reference.md は「typed timestamp が要るとき posts_current」と一般原則は書くが、posts_view の created_at が文字列である点と cast 回避策は明記が無い。直すなら reference.md の posts_view 説明に「created_at は ISO-8601 文字列 ── interval 演算は cast か posts_current」を 1 行足す。関連 PR #354。