[aside] D-C 後、owner の owner_handle 解決が NULL になる ── did_handle_cache が did:plc キーのまま残り token.owner_did(did:webvh)と join が外れる

PR #278(D-C principal rewrite)作業中に確認した cutover〜②b 間の interim degradation。

- **構造**: `verify_token`(`src/auth/store.rs`)は `LEFT JOIN did_handle_cache c ON c.did = t.owner_did` で `TokenInfo.owner_handle` を埋める。D-C は `token.owner_did` を did:webvh に rewrite するが `did_handle_cache` は touch しない(brief で author_handle 供給源 = ②b と明示分離)。さらに OAuth callback(`src/oauth/atproto.rs`)は handle を依然 did:plc キーで `record_did_handle` するので、cutover 後は owner の cache 行が did:plc キー / token は did:webvh で join が外れ `owner_handle = NULL`。
- **影響範囲**: authz(`authorize_owner`)は owner_did で判定するので「token が owner として通る」は満たす(D-C のゴール)。壊れるのは author_handle 表示 / agent account 自動 provision(`<owner>/<slug>` が組めない)。
- **触らない判断**: brief frozen が token store = owner_did のみと明示、author_handle 供給源は ②b。did_handle_cache の re-key は handle 供給路を触るので ②b スコープ。PR body にも明記済。
- **想定インパクト / トリガー**: 単一 owner の pre-alpha なので実害は限定的だが、②b(OAuth/atrium 撤去 + author_handle rework)で「did:webvh principal の owner_handle をどう供給するか」を必ず扱う必要あり。対応案 — (a) did:webvh の handle を別ルートで解決して cache 投入、(b) owner_handle を owner_identity 等から引く、(c) ②b で OAuth ごと撤去する際に handle 供給を作り直す。② 着手時に回収。