feat(scripting): ScriptWorker isolation on Windows: restricted worker identity, pipe ACL, firewall + PeCacheDir installer (lmxopcua#780)

Owner decisions §14 #5/#6 as built (design §12.5):

- Scripting:Worker:Identity (default unset, Windows only, fail-closed validation): each worker
  starts under a restricted token derived from the host's. Every privilege but SeChangeNotify is
  removed; the restricting SIDs are NT SERVICE\OtOpcUaScriptWorker's SID + Everyone + Users +
  RESTRICTED; the token and default DACLs are host + SYSTEM + identity + RESTRICTED. The worker
  is created suspended, put in its Job Object before it runs, inherits only its stdio pipes, gets
  an ACL'd work dir as TEMP, and runs with DOTNET_EnableDiagnostics=0. The identity is granted on
  the host's window station and desktop, because USER32 init made coreclr.dll fail with
  ERROR_DLL_INIT_FAILED on windev. The logon SID is not used because the host's process DACL
  gives it PROCESS_VM_READ.
- The worker pipe on Windows always has an explicit protected DACL: host account + identity
  only. There is no owner ACE, so an elevated host's Administrators gets no access.
- The worker treats access denied on its parent-pid poll as alive; the Job Object covers that case.
- scripts/install/Install-ScriptWorkerIsolation.ps1 + ScriptWorkerIsolation.psm1 are idempotent
  and support -WhatIf, -Uninstall and -PlanOnly. They create the disabled anchor service, the
  PeCacheDir ACL (protected, no Users, key and markers host-only, pe\ Modify for the identity),
  read+execute on script-worker\, a ReadData deny on the install root, the outbound firewall
  block on the worker exe, and optionally the host-service env.
- Tests: the dry-run harness scripts/install/tests/Test-ScriptWorkerIsolation.ps1 (46
  assertions, mutation-checked); ScriptWorkerIdentityTests; WorkerIsolationTests, which cover
  the pipe ACL, token access and a real restricted worker running a script, all green on windev.

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

src/Core/ZB.MOM.WW.OtOpcUa.Core.Scripting.OutOfProcess/WindowsJobObject.cs

@@ -29,6 +29,16 @@ internal sealed class WindowsJobObject : IDisposable
     /// <param name="processMemoryLimitBytes">The per-process commit limit.</param>
     /// <returns>The job; dispose it to kill the worker.</returns>
     public static WindowsJobObject Assign(Process process, long processMemoryLimitBytes)
+        => Assign(process.Handle, processMemoryLimitBytes);
+
+    /// <summary>
+    ///     Creates a job with the worker limits and assigns the process behind <paramref name="processHandle"/> to it — the
+    ///     restricted launch assigns its worker while it is still suspended (<see cref="RestrictedWorkerLauncher"/>).
+    /// </summary>
+    /// <param name="processHandle">A handle with <c>PROCESS_SET_QUOTA</c> and <c>PROCESS_TERMINATE</c>.</param>
+    /// <param name="processMemoryLimitBytes">The per-process commit limit.</param>
+    /// <returns>The job; dispose it to kill the worker.</returns>
+    public static WindowsJobObject Assign(IntPtr processHandle, long processMemoryLimitBytes)
     {
         var handle = CreateJobObjectW(IntPtr.Zero, null);
         if (handle.IsInvalid) throw new Win32Exception(Marshal.GetLastWin32Error(), "CreateJobObject failed");
@@ -48,7 +58,7 @@ internal sealed class WindowsJobObject : IDisposable
             if (!SetInformationJobObject(handle, JobObjectExtendedLimitInformation, ref info,
                     (uint)Marshal.SizeOf<JOBOBJECT_EXTENDED_LIMIT_INFORMATION>()))
                 throw new Win32Exception(Marshal.GetLastWin32Error(), "SetInformationJobObject failed");
-            if (!AssignProcessToJobObject(handle, process.Handle))
+            if (!AssignProcessToJobObject(handle, processHandle))
                 throw new Win32Exception(Marshal.GetLastWin32Error(), "AssignProcessToJobObject failed");
             return job;
         }