[aside] `delete_group` の empty-guard(`authorize_group_empty`)は live post と extra member は数えるが、その group を audience にした **live curation を数えない** ── PR #345 で curations_raw.deleted を routing index に足した今、データはあるのに guard が引いていない

PR #345(delete_group guard の dead-read 修正)実装中に気付いた、今回スコープ外の対称な穴。

- **事実**: `authorize_group_empty`(`src/server.rs` ~2010)は (a) `SELECT COUNT(*) FROM posts_raw WHERE audience_group_id = ? AND deleted = FALSE` と (b) `group_members` の extra count しか見ない。`curations_raw` は照会しない。
- だが `create_curation` は `audience_group_id` を取れる(private group を curation の audience にできる)。なので **live curation だけが残る group は guard を素通りして削除でき**、curation の audience が dangling(削除済 group 参照)になる ── post の場合に guard が防いでいるのと同じ integrity 懸念。
- 皮肉な点: PR #345 で `apply_routing_only` に **CurationDeleted の tombstone(`curations_raw.deleted = TRUE`)を追加**したので、routing index は今や live curation を数えるデータを持っている。しかし `curations_raw.deleted` を読む消費者が無い(`event_bucket`/`audience_of_curation` は audience だけ見て deleted は無視)── つまり私が足した curation tombstone は現状 **write-only**。guard がそれを数えれば消費者になる。

触らない判断: PR #345 は post-count guard の dead-read 修正が scope。curation を guard に足すのは別 PR(挙動変更を伴う = 削除可否が変わる)。

想定インパクト / トリガー: live trigger = private group を curation の audience にしている状態で delete_group を叩く。user の運用は大半 g_public + curation の private audience 利用も限定的なので latent。直すなら `authorize_group_empty` に `SELECT COUNT(*) FROM curations_raw WHERE audience_group_id = ? AND deleted = FALSE` を足し、>0 なら「live curation(s) still target this group」で reject(post 側と対称)。関連 PR #345、dead-read cluster の aside n_01KT47CQE(あちらは delete_group guard の posts_raw 空読みと claim_goose_jobs ── curation 軸は未記載)。