[low-pri] binding 导出/导入 API：换社区免二次绑定（只搬通知绑定，绝不导私钥）

[jhfnetboy]

优先级：低。记录设计共识，后续开发。来源：2026-07-06 KMS+DVT 单板架构讨论。

目标

用户从社区 A 迁移到社区 B（各社区 KMS 独立、passkey rpId 锚定各自域名 → 换社区=换 passkey）时，把已验证的 通知联系方式绑定（telegram + email，contact_bindings 表）搬到新社区 KMS，免去重新走 begin-binding 二次验证的繁琐。

硬边界（不可越）

• 绝不导出私钥。 私钥导出 (export_key CLI) 是 DEV/TEST-only feature（kms/host/Cargo.toml:58 门控），生产 HTTP 不暴露，保持现状。
• 社交恢复 / 私钥迁移不归 KMS —— 那是 airaccount-contract（合约账户）的能力。本 issue 只搬 contact_bindings。

信任模型：A（拥有者自证）

不做跨 KMS 实例验签（违背半去中心化、各社区独立域名）。信任落在两端 passkey 认证 + 密文完整性。理由：只搬通知数据，最坏后果是通知劫持（有限危害）；导入被新账户 passkey 门控，攻击者无法往他人账户塞绑定。

流程（Tier 1，推荐）

1. 导出：旧 KMS 上 passkey 验证通过 → KMS 生成 自持的一次性密文 bundle（内容=该账户的 contact_bindings：channel/contact_ref/display_hint 等）+ 短 TTL（如 10 min）+ authenticated（防篡改）+ one-time（用后失效）。以 QR/码给用户。
2. 导入：新 KMS 上 passkey 验证新账户 → 粘贴密文 → 只挑一个渠道做 liveness 二选一（email 点确认链接 或 telegram 回验证码，任一即可）→ 全部绑定导入完成。

简化点：把「逐个渠道 re-verify」压成「一次 liveness（二选一）」。密文的 one-time + 短 TTL + 两端 passkey 已覆盖伪造/重放/越权；liveness 只兜"旧联系方式已废弃/回收"这个边角。

待定

• Tier 0（零 re-verify）vs Tier 1（一次 liveness） —— 倾向 Tier 1。若要极致零摩擦可退到 Tier 0（纯通知数据可接受）。
• 密文加密/解锁密钥：一次性 + 短 TTL 前提下，用什么密钥封装（passkey 派生 vs 服务端一次性对称密钥）。
• 端点形态：POST /contact/export（passkey-gated）+ POST /contact/import（passkey-gated + liveness）。

关联

• contact_bindings 表见 kms/host/src/db.rs（[评估] 通知绑定方案的 KMS 部分(owner 验证/bindingCode/存储)— 见 aastar-sdk#193 #129，telegram+email 均已支持，contact_ref at-rest 加密，PII）。
• 上层背景：KMS+DVT 单板 co-location（极致省内存 / 最高并发）架构讨论。