feat(acl): variable-depth scope model + the scopePaths producer (#520 stage 3)

Makes the /raw device tree addressable by an ACL rule, and builds the
scope-path producer PermissionTrieBuilder has accepted since it was written
but which had no caller anywhere.

The plan for this stage said "add NodeHierarchyKind.Raw, whose path is the
RawPath segments Folder/Driver/Device/TagGroup/Tag". That shape is wrong.
RawFolder.ParentRawFolderId and TagGroup.ParentTagGroupId are both
self-referencing, so folders and tag groups each nest without bound and a real
RawPath is folder…/Driver/Device/group…/Tag. NodeScope was fixed-arity and
PermissionTrie.CollectMatches was five hardcoded steps, so the scope model
could not address a real raw tree at all. NodeScope is now {ClusterId, Kind,
Segments} and the walk is a segment loop. The trie STRUCTURE was already
variable-depth (NodeAclPath.Segments is a list, Children is a recursive
dictionary), so only the walker and the scope record had to change.

Four decisions worth keeping:

- The namespace level became the realm. Level 1 gated on NodeScope.NamespaceId,
  but v3 has no Namespace entity — the snapshot was retired when the address
  space went dual-namespace, and the identifier appears nowhere in production
  outside NodeScope. So the level could only ever fail to match, which silently
  made every sub-cluster grant unreachable while cluster grants kept working.
  It is now a realm token derived from the scope's Kind, not carried on it, so
  the walk and the producer cannot disagree about its spelling.
- Provenance comes from the granting row's own ScopeKind, recorded on TrieGrant
  at build time. Depth-derived provenance could not name a raw level at all,
  since the depth of "Device" varies with folder nesting.
- The trie comparer moved from OrdinalIgnoreCase to Ordinal. Raw sibling-name
  uniqueness is ordinal, so Speed and speed can both exist under one device and
  a grant on either would have matched both.
- The null-scopePaths "deterministic test mode" is deleted. It planted
  unresolvable rows at a direct child of the trie root, a position the walker
  cannot reach, so the grant looked placed and could never match — and every
  test using that mode proved nothing about production placement. scopePaths is
  now required, and a row that does not resolve is dropped with a diagnostic.

A scope resolves to a LIST of paths: a raw tag projected into N equipments is
reachable at N+1 NodeIds and a write through any of them lands on the same
driver reference, so a Tag-scoped grant covering only the raw node would be
bypassable through a UNS one. The lookup is keyed on (ScopeKind, ScopeId), not
ScopeId alone — ScopeId has no FK and no type discriminator, so an id collision
across entity types would hand a grant the wrong node's paths.

Also closed here, all found by review rather than asked for:

- NodeAcl rows had no deploy-time validation of any kind and were not reachable
  from DraftValidator at all (DraftSnapshot carried no NodeAcls). They are now
  gated for dangling ids, cross-cluster scopes, blank/contradictory ScopeId, the
  retired FolderSegment kind, and undefined ordinals.
- ConfigDbApiKeyStore conferred roles from Cluster-scoped grants authored in ANY
  cluster, because it filtered on scope kind with no ClusterId predicate while
  ArtifactApiKeyStore read an already-cluster-filtered snapshot. On a fused
  admin+driver node that was a cross-cluster over-grant. Its doc comment claimed
  the two stores matched.
- The two AdminUI ACL banners still said enforcement was LDAP-group -> role
  mapping, which stages 1/2 made false in both directions.
- The /apikeys page was never classified in PageAuthorizationGuardTests, so that
  test has been red since the key-minting commit merged — I did not run
  AdminUI.Tests before merging stage 4.

Falsified rather than assumed: 8 mutations against the trie tests, 5 against the
deploy gate (including one proving a cross-cluster row is not silently
mis-diagnosed as unresolved), a staged red->green for the over-grant regression,
and the realm gate, the comparer and the malformed-path guard each broken
individually to confirm only their own tests go red.

Node ACLs are still not ENFORCED — nothing constructs a NodeScope or calls the
evaluator yet. That is stages 5 and 6; this stage makes the model able to
express what those will enforce.

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

src/Core/ZB.MOM.WW.OtOpcUa.Configuration/Enums/NodeAclScopeKind.cs

@@ -1,18 +1,62 @@
 namespace ZB.MOM.WW.OtOpcUa.Configuration.Enums;
 
 /// <summary>ACL scope level. Per <c>acl-design.md</c> §"Scope Hierarchy".</summary>
+/// <remarks>
+///     ⚠️ <b>Append new members only — never insert.</b> SQL Server stores this as a string
+///     (<c>nvarchar(16)</c>, so a member name must also stay ≤ 16 characters), but the deployment
+///     artifact serialises it as the <b>integer ordinal</b> and the node-side decoder reads it back
+///     with <c>Enum.IsDefined</c>. Inserting a member mid-enum silently re-maps every grant in every
+///     already-deployed artifact to a different scope level.
+/// </remarks>
 public enum NodeAclScopeKind
 {
+    /// <summary>The whole cluster — the only kind that carries a null <c>ScopeId</c>.</summary>
     Cluster,
-    Namespace,
-    UnsArea,
-    UnsLine,
-    Equipment,
+
     /// <summary>
-    ///     A folder segment anchored below a namespace (used for FolderPath-scoped tags).
-    ///     Distinguishes folder grants from UNS <see cref="Equipment"/> grants in the
-    ///     <c>AuthorizationDecision.Provenance</c> audit trail and Admin UI diagnostics.
+    ///     One whole OPC UA namespace (realm). <c>ScopeId</c> is the realm token <c>raw</c> or
+    ///     <c>uns</c>; see <c>NodeAclRealms</c>, which is the single authority for that spelling.
+    /// </summary>
+    Namespace,
+
+    /// <summary>A UNS area. <c>ScopeId</c> is a <c>UnsArea.UnsAreaId</c>.</summary>
+    UnsArea,
+
+    /// <summary>A UNS line. <c>ScopeId</c> is a <c>UnsLine.UnsLineId</c>.</summary>
+    UnsLine,
+
+    /// <summary>A UNS equipment. <c>ScopeId</c> is an <c>Equipment.EquipmentId</c>.</summary>
+    Equipment,
+
+    /// <summary>
+    ///     ⚠️ <b>Retired v2 concept — do not author new rows with this kind.</b> It described a folder
+    ///     segment under the v2 <c>SystemPlatform</c>/Galaxy hierarchy, which v3 deleted along with the
+    ///     <c>WalkSystemPlatform</c> walker. The v3 replacement is <see cref="RawFolder"/>. The member
+    ///     survives only because removing it would shift every later ordinal in already-deployed
+    ///     artifacts; a row still carrying it resolves no scope path and is reported as an unresolved
+    ///     scope by the deploy gate.
     /// </summary>
     FolderSegment,
+
+    /// <summary>
+    ///     A single tag. <c>ScopeId</c> is a <c>Tag.TagId</c> — i.e. a <b>raw</b> tag, which is the only
+    ///     kind of tag v3 has. Because one raw tag can be projected into several equipments by
+    ///     <c>UnsTagReference</c> rows, a Tag-scoped grant resolves to <b>several</b> trie paths: the raw
+    ///     node plus every UNS projection of it. That is deliberate — a write routes to the same driver
+    ///     reference through either NodeId, so a grant that covered only one of them would be bypassable
+    ///     through the other.
+    /// </summary>
     Tag,
+
+    /// <summary>A raw-tree folder. <c>ScopeId</c> is a <c>RawFolder.RawFolderId</c>. (v3; appended.)</summary>
+    RawFolder,
+
+    /// <summary>A raw-tree driver instance. <c>ScopeId</c> is a <c>DriverInstance.DriverInstanceId</c>. (v3; appended.)</summary>
+    RawDriver,
+
+    /// <summary>A raw-tree device. <c>ScopeId</c> is a <c>Device.DeviceId</c>. (v3; appended.)</summary>
+    RawDevice,
+
+    /// <summary>A raw-tree tag group. <c>ScopeId</c> is a <c>TagGroup.TagGroupId</c>. (v3; appended.)</summary>
+    RawTagGroup,
 }