docs: clarify Instance identity and deletion semantics

docs/domain-model.md

@@ -1,6 +1,6 @@
 # 领域模型设计草案
 
-状态：Draft，待评审。日期：2026-09-12。
+状态：Draft，含已确认决策。日期：2026-09-13。
 
 本文定义领域职责、身份与一致性边界，并用对象规格细化字段和方法合同；方法使用
 设计签名，不固定 Go 目录、SDK 或框架，也不批准实现。外部行为以
@@ -124,12 +124,11 @@ phase 只决定候选步骤，外部证据决定该步骤是否允许执行、
 测试验证 checkpoint 持久化和重启恢复；E2E 验证最终合同。不能只验证一串 mock 调用
 就声称实现了最终一致性。
 
-## 6. 批准前需明确的边界
+## 6. 决策记录与待细化边界
 
-1. **Instance 身份与物理目标**：规格允许 endpoint 变化，但同一个 Instance UID 指向
-   另一台服务器，或者多个 Instance 指向同一台服务器时，既有 Claim 怎么解释？不能
-   仅凭 CR UID 判断物理隔离，或将已有租户无声迁移。需决定限制还是引入可验证的
-   服务器／安装身份；本文不新增限制。
+1. **Instance 身份与物理目标（已确认）**：以管理员声明为准，endpoint 变更不验证
+   物理服务器／registry 连续性，不增加安装身份绑定检查；旧观察失效，重验新配置
+   的连接与管理能力。新 CR 视为新 Instance，不自动接管旧 UID 资源或迁移数据。
 2. **Retain 完成条件**：外部依赖不可用不能永久阻止 CR 删除，但 registry 又需标记
    unmanaged。需定义 CR 消失后的补偿／清扫入口及所需身份依据，不能承诺同时原子
    完成两者，也不能在没有回读时声称已写入保留标记。
@@ -142,5 +141,9 @@ phase 只决定候选步骤，外部证据决定该步骤是否允许执行、
    不可变”。应明确绑定在认领、首次外部写入还是 Ready 时固定，及如何在 status 丢失
    后恢复；否则供应中途改名称可能产生无人管理的资源。
 
-本轮先评审第 1–3 节的对象与职责划分；上述问题记录在案，相关用例在决策批准前不
-进入实现。下一份小改动只细化一个用例，不同时实现整套模型。
+5. **Instance 删除（已确认）**：开始受管即添加 finalizer；删除期间停止新供应，
+   有 Tenant 引用就等待，无引用才解除，不级联删除外部资源。首版采用 finalizer
+   与引用检查，不引入跨对象锁／准入控制；不保证并发创建与删除的原子性。
+
+Tenant 的 Retain 等待决行为留到 Tenant 设计，不属于本轮 Instance 设计范围。
+相关用例在决策批准前不进入实现，不同时实现整套模型。