fix(review): resolve deferred code-review findings; S7.Cli verdict, browser CP release, MemberLeft/Exited/Downed, Sql Detach hoist (#625)

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe

code-reviews/Runtime/findings.md

@@ -62,7 +62,7 @@ alarms (`ScriptedAlarmHostActor.cs`, `EfAlarmConditionStateStore.cs`,
 | Severity | Medium |
 | Category | Correctness & logic bugs |
 | Location | `src/Server/ZB.MOM.WW.OtOpcUa.Runtime/OpcUa/OpcUaPublishActor.cs:311-318`; cross-module `src/Server/ZB.MOM.WW.OtOpcUa.OpcUaServer/AddressSpacePlan.cs:56-61` + `src/Core/ZB.MOM.WW.OtOpcUa.Commons/OpcUa/IOpcUaAddressSpaceSink.cs:55` |
-| Status | Deferred |
+| Status | Resolved |
 
 **Description:** This is the Runtime side of the orchestrator-handed cross-module item **OpcUaServer-001**:
 a UNS Area/Line *rename* (display-name-only edit, no Equipment/Tag/Driver/Alarm change) produces an
@@ -90,7 +90,7 @@ is necessary but not sufficient.
 `HandleRebuild` runs `MaterialiseHierarchy` for a non-empty UNS-only plan (it already does, since the
 short-circuit only fires for a truly-empty plan). No Runtime-only change can close it safely.
 
-**Resolution:** _(deferred — needs OpcUaServer `AddressSpacePlan` rename signal + Commons `EnsureFolder`/`RenameFolder` rename semantics; both outside the Runtime edit boundary. Tracked with OpcUaServer-001.)_
+**Resolution:** Resolved (verified 2026-10-08, #625) — closed by OpcUaServer-001: `AddressSpacePlanner` now diffs `UnsAreas`/`UnsLines` renames (`DiffRenames`), so a display-name-only rename is no longer `IsEmpty`, and the sink renames the existing folder in place. The surgical-deploys work did not change this path.
 
 ### Runtime-002