[aside] `pair.tsx`(CLI handoff)と custody(browser)が master_seed を別フローで独立管理 ── 同じ seed を使う保証が無く、ユーザが 2 つの食い違う seed を作れてしまう(PR #265 スコープ外)

PR #265(browser custody/復旧)を組む中で気付いた、識別子層のシーム。

- `web/src/pair.tsx` は CLI pairing 用に seed を**乱数生成 or base64 貼り付け** → loopback で CLI に POST → 直後に破棄(browser には残さない)。CLI 側 session cache に seed が入る。
- 本 PR の custody(`custody-session.ts` / `unlock-seed.tsx`)は **browser 側**で seed を wrap して IndexedDB に保存し、SPA 復号に使う。setup は「新規生成 / base64 import / 24語復旧」。
- 両者は「master_seed をセットアップする」UI を**独立に 2 つ**持ち、リンクも警告も無い。`pair` で `新規生成`、custody でも `新規生成` すると **別々の seed が 2 つ**でき、CLI 由来 group 鍵と SPA 由来 group 鍵が食い違って相互に復号不能になる。
- 正しい使い方は「片方で作った seed を base64 / 24語でもう片方に持ち込む」だが、UI 上それを促す導線が無い(custody の base64 import で揃えられはする)。

直さない判断:本 PR は browser custody 単体が scope。pairing は CLI handoff の別 surface で、統合は UX 設計判断(どちらを seed の source of truth にするか)を要する別軸。挙動は壊れていない(揃えれば動く)。

想定インパクト:低頻度だが踏むと分かりにくい ── 「SPA で復号できない post がある / CLI と SPA で見える秘密が違う」が seed 不一致由来だと気付きにくい。① did:webvh(seed が identity root になる)に進むと seed 一意性の前提がより重くなる。

トリガー / 方向案:pairing か custody を次に触るとき。(a) pairing 完了後に「同じ seed で browser custody も設定しますか」を出す、(b) custody setup で既存 pairing seed があれば import を促す、(c) 最低限、両 setup の「新規生成」で「既にこの端末/CLI に seed があるなら揃えてください」を warn。関連 [[project_quacker_identity_account_direction]](seed が単一 root)。