docs(alarms): OPC UA Enable/Disable wired + native-ack→AVEVA with principal + HistoryUpdate permission bit

docs/security.md

@@ -205,6 +205,7 @@ public enum NodePermissions : int
     AlarmConfirm      = 1 << 9,
     AlarmShelve       = 1 << 10,
     MethodCall        = 1 << 11,
+    HistoryUpdate     = 1 << 12,   // OPC UA annotation / insert / delete (separate from HistoryRead)
 
     ReadOnly  = Browse | Read | Subscribe | HistoryRead | AlarmRead,
     Operator  = ReadOnly | WriteOperate | AlarmAcknowledge | AlarmConfirm,
@@ -215,6 +216,8 @@ public enum NodePermissions : int
 
 The three Write tiers map to Galaxy's v1 `SecurityClassification` — `FreeAccess`/`Operate` → `WriteOperate`, `Tune` → `WriteTune`, `Configure` → `WriteConfigure`. `SecuredWrite` / `VerifiedWrite` / `ViewOnly` classifications remain read-only from OPC UA regardless of grant.
 
+`HistoryUpdate` (bit 12) is a **separate** permission from `HistoryRead` so a read-only grant cannot also authorize OPC UA HistoryUpdate (annotation / insert / delete) operations. `TriePermissionEvaluator` maps `OpcUaOperation.HistoryUpdate` to this bit, closing the read⇒update hole that existed when the only history permission was `HistoryRead`. Note: `HistoryUpdate` is **not** included in any composite bundle (`ReadOnly` / `Operator` / `Engineer` / `Admin`) because the HistoryUpdate service surface (the actual insert/replace/delete backend RPC) is not yet implemented — a client calling HistoryUpdate still receives the SDK's default reject regardless of the grant.
+
 ### Evaluator — `PermissionTrie`
 
 `src/Core/ZB.MOM.WW.OtOpcUa.Core/Authorization/`: