Closes the last gap from phase 3.5: web-created topics start as v1
plaintext (mutations.ts ensureGeneralTopic doesn't generate a key,
because the dashboard owner has a throwaway pubkey with no secret).
Once the browser identity is registered via /v1/me/peer-pubkey, the
chat panel can lazily upgrade the topic to v2.
API (POST /v1/topics/:name/claim-key)
- Atomic claim: only succeeds when topic.encrypted_key_pubkey IS
NULL. Body carries the new senderPubkey + the caller's sealed copy
of the freshly-generated topic key. Race losers get 409 with the
winning senderPubkey so they fall through to the regular fetch
path. Idempotent at topic_member_key level.
Web
- claimTopicKey() in services/crypto/topic-key.ts: generates a fresh
32-byte symmetric key, seals for self, POSTs the claim. Returns
the in-memory key so the caller can encrypt immediately without a
follow-up GET /key round-trip.
- sealTopicKeyFor(): mirrors the CLI helper so a browser holder can
re-seal for newcomers (CLI peers, other browsers) instead of the
topic going dark when only a browser has the key.
- TopicChatPanel: when keyState === "topic_unencrypted", composer
now shows a "🔓 plaintext (v1) — encryption not yet enabled" line
with an "enable encryption" button. Click → claimTopicKey → state
flips to "ready" → 🔒 v0.3.0 banner appears. On race-lost, falls
through to fetch.
- New 30s re-seal loop fires while holding the key: polls
/pending-seals, seals via sealTopicKeyFor for each pending target,
POSTs to /seal. Same cadence + soft-fail discipline as the CLI.
Net effect: any dashboard user can convert legacy v1 topics to v2
with a single click, and CLI peers joining later will receive a
sealed copy from the browser's re-seal loop without manual action.
7f6af0137d